@@ -318,9 +318,9 @@ func NewDeltaFIFO(keyFunc KeyFunc, knownObjects KeyListerGetter) *DeltaFIFO {
318318
3193191 .  List etcd 中(通过 kube-apiserver,下同)特定类型的所有对象,然后调用 DeltaFIFO 的 ` Replace() `  方法,将他们同步到 DeltaFIFO;
3203202 .  根据配置的 Resync 时间,** 周期调用**  DeltaFIFO 的 ` Resync() `  方法(见后文),将 knownObjects 中的对象更新到 DeltaFIFO 中;
321- 3 .  阻塞  Watch etcd,根据事件的类型分别调用 DeltaFIFO 的 Add/Update/Delete 方法,将对象更新到 DeltaFIFO;
321+ 3 .  Watch etcd,这是阻塞式的 ,根据事件的类型分别调用 DeltaFIFO 的 Add/Update/Delete 方法,将对象更新到 DeltaFIFO;
322322
323- Watch etcd 会** 周期性的** 超时(因为设置了 timeout),当  ` ListAndWatch() `  出错返回时 ,Reflector 会等待一段时间再执行它,从而周期的将  ` etcd `  中的特定类型对象 ** 的全部对象 ** 同步到 ` DeltaFIFO ` 。
323+ Watch etcd 会** 周期性的** 超时,这时  ` ListAndWatch() `  出错返回 ,Reflector 会等待一段时间再执行它,从而实现 ** 周期的将  ` etcd `  中的特定类型的全部对象 ** 同步到 ` DeltaFIFO ` 。
324324
325325** ` controller `  是 ` DeltaFIFO `  的消费者,它用 DeltaFIFO 弹出的对象更新 ` knownObjects `  缓存,然后调用注册的 OnUpdate/OnAdd/OnDelete 回调函数** 。详情参考 [ Reflector] ( 3.reflector.md )  和 [ controller 和 Informer] ( 4.controller-informer.md )  文档。
326326
@@ -336,7 +336,7 @@ type Delta struct {
336336}
337337``` 
338338
339- 有一种特殊情况:当 Reflecter  重复执行 ` ListAndWatch() `  方法时,List etcd 获取的对象集合 set1 可能与 knownObjects 缓存中的对象集合  set2 ** 不一致** ,调用的  Replace() 方法会发现这种情况,将位于 set1 但不在 set2 中的对象生成 ` DeletedFinalStateUnknown `  类型事件:
339+ 有一种特殊情况:当 Reflector  重复执行 ` ListAndWatch() `  方法时,List etcd 获取的对象集合 set1 可能与 knownObjects 的对象集合  set2 ** 不一致** (见后文详细分析),但这时调用的 DeltaFIFO  Replace() 方法会发现这种情况,将位于 set1 但不在 set2 中的对象生成 ` DeletedFinalStateUnknown `  类型事件,后续 controller 弹出该事件时将对象从 knownObjects 删除,从而保证两者一致 :
340340
341341```  go 
342342type  DeletedFinalStateUnknown  struct  {
@@ -347,9 +347,9 @@ type DeletedFinalStateUnknown struct {
347347}
348348``` 
349349
350- 之所以不用 Type 为 Deleted 的 Delta 来表示 ,是因为:etcd 中没有该对象,Reflector ** 不知道** 这个对象的当前值,所以只能用一个有别与 Deleted Delta 类型的特殊类型来表示这种情况 。
350+ 之所以不用 Type 为 Deleted 的 Delta 来表示这种事件 ,是因为:etcd 中没有该对象,Reflector ** 不知道** 这个对象的当前值,所以只能用一个特殊类型来表示 。
351351
352- ** 有且只有 ** ` Replace() `  方法才会产生  ` DeletedFinalStateUnknown `  类型事件 。
352+ ` Replace() `  是 ** 唯一 ** 产生  ` DeletedFinalStateUnknown `  类型事件的方法 。
353353
354354### Add() 和 Update() 方法  
355355
@@ -364,7 +364,7 @@ func (f *DeltaFIFO) Add(obj interface{}) error {
364364}
365365``` 
366366
367- ` Update() `  方法和 ` Add() `  方法类似,差别在于产生的是 ` Updated `  Delta 类型事件 ;
367+ ` Update() `  方法和 ` Add() `  方法类似,差别在于产生的是 ` Updated `  Delta 事件 ;
368368
369369### queueActionLocked() 方法  
370370
@@ -419,15 +419,20 @@ func (f *DeltaFIFO) queueActionLocked(actionType DeltaType, obj interface{}) err
4194191 .  遍历 list 中的对象,为每个对象生成 ` Sync `  事件;
4204202 .  遍历 f.knownObjects.ListKeys() 中的对象,对于不在传入的 list 中的对象,生成 ` Deleted `  事件,对象类型为 ` DeletedFinalStateUnknown ` (非 Delta 类型);
421421
422- Reflecter 周期调用  Replace() 方法将  etcd 中的特定类型的所有对象同步到 DeltaFIFO 中。` controller `  用 DeltaFIFO 弹出的对象更新 ` knownObjects `  缓存,详情参考 [ Reflector] ( 3.reflector.md )  和 [ controller 和 Informer] ( 4.controller-informer.md )  文档。
422+ Reflector 的  ` ListAndWatch() `  因 Watch 超时而周期调用  Replace() 方法,将  etcd 中的特定类型的所有对象同步到 DeltaFIFO 中。` controller `  用 DeltaFIFO 弹出的对象更新 ` knownObjects `  缓存,详情参考 [ Reflector] ( 3.reflector.md )  和 [ controller 和 Informer] ( 4.controller-informer.md )  文档。
423423
424424### Resync() 方法  
425425
426- 遍历 f.knownObjects.ListKeys() 中的对象:
427-  对于某个对象 id,如果 f.items[ id]  有值(长度 > 0),则跳过;
428-  否则,生成 Sync 事件:f.queueActionLocked(Sync, obj)
426+ 遍历 knownObjects 中的对象:
429427
430- 综上,** Replace() 和 Rsync() 方法会会生成 Sync 事件** 。
428+ 1 .  如果该对象位于事件缓存 f.items 中,则跳过;
429+ 2 .  否则,生成 Sync 事件;
430+ 431+ 前文我们提到 DeltaFIFO 的使用场景之一是:** "你想周期处理所有的对象"** ,但对象一旦从 DeltaFIFO 中弹出,如果没有产生新的 Watch 事件,就不会对它再调用注册的回调函数。
432+ 433+ Reflector 的 ` ListAndWatch() `  方法周期执行 DeltaFIFO 的 Resync() 方法,目的就是** 为对象产生新的 Sync 事件** ,从而有机会再次调用注册的 ` OnUpdate() `  处理函数。因此 Resync 时,如果对象已经在 f.items,则后续由机会被弹出,所以不需要为它生成 Sync 事件。
434+ 435+ ** Replace() 和 Rsync() 方法会会生成 Sync 事件** 。
431436
432437### Pop() 方法  
433438
@@ -491,8 +496,7 @@ func (f *DeltaFIFO) HasSynced() bool {
491496
4924974 . ListAndWatch () 方法起一个 goroutine,周期的调用 Resync () 方法将 knownObjects 中的对象更新到 DeltaFIFO ,为何要这么做呢?
493498
494-  在前文我们提到 DeltaFIFO  的使用场景之一是:**"你想周期处理所有的对象"**,但对象一旦从 DeltaFIFO  中弹出,如果没有产生新的 Watch  事件,就不会对它再调用注册的回调函数。而周期执行 Resync () 方法的目的就是**为对象产生新的 Sync  事件**,从而有机会再次调用注册的 ` OnUpdate()`   处理函数。基于此,Resync 时,如果对象已经在 f.items  中,则有机会被弹出,所以不需要为它生成 Sync  事件。
495- 499+  前文我们提到 DeltaFIFO  的使用场景之一是:**"你想周期处理所有的对象"**,但对象一旦从 DeltaFIFO  中弹出,如果没有产生新的 Watch  事件,就不会对它再调用注册的回调函数。Reflector 的 ` ListAndWatch()`   方法会周期执行 DeltaFIFO  的 Resync () 方法,目的就是**为对象产生新的 Sync  事件**,从而有机会再次调用注册的 ` OnUpdate()`   处理函数。因此 Resync  时,如果对象已经在 f.items ,则后续由机会被弹出,所以不需要为它生成 Sync  事件。
496500
497501后续文章会介绍,` controller`   一般是在 ` Informer`   中使用的,` controller`   调用的 ` OnUpdate()`   函数实际会调用用户创建 ` Informer`   时传入的 ` ResourceEventHandler`   中的 ` OnUpdate()`   函数。所以用户的 ` OnUpdate()`   函数可能会因 DeltaFIFO  的周期 Resync () 而被调用,它应该检查传入的 old、new 对象是否发生变化,未变化时应该忽略:
498502
0 commit comments