@@ -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