\345\237\272\344\272\216k8s\345\256\236\347\216\260\345\205\203\346\225\260\346\215\256\347\232\204\345\220\214\346\255\245.md
... ...
@@ -360,7 +360,7 @@ class AppModelEventHandlerImpl implements AppModelEventHandler {
360 360
```
361 361
在上面的代码和注释中,我们定义了一个AppModelEventHandler接口,用于处理crd的增删改事件,然后在实现类中实现了对app模型元数据的增删改操作。一旦crd中数据发生变化,就会触发对应的事件处理方法,从而实现了元模型数据在多个pod中的内存同步。
362 362
需要注意的是,app和model 都是保存有自己的版本号,所以在更新的时候需要判断版本号是否一致,如果一致,则说明没有更新,直接返回即可,如果版本不一致则需要重新从redis加载最新版本的value。在大部分情况下一般version都是一致,但是如果消费事件异常可能会导致不一致,这个时候k8s也提供了resync机制来重新同步一次数据(注意不是同步事件,而是数据本身)。
363
-
363
+
364 364
为什么要引入版本号version呢?主要是为了性能,因为k8s自带resync机制(为了解决事件消费失败问题),会将已有的数据以update事件定期重新同步到内存中,如果不判断版本号,则会导致每次都更新内存中的数据,且每次都需要从redis中获取value数据,造成很多无谓的性能浪费。
365 365
366 366
参考:[Informer 中为什么需要引入 Resync 机制?](https://github.com/cloudnativeto/sig-kubernetes/issues/11)