导语
近期专项定位某个服务的用户反馈，其中有个业务使用zookeeper进行配置同步，但发现延时1——20分钟不等，导致数据加载不及时，引起一系列问题。
服务架构
image.png
- 接入层负责接入大量的客户端请求，对实时性要求高
- 由于接入层实时性要求高，服务B配置信息均加载到内存，变更的情况通过ZK进行实时通知，然后从MDB加载变更数据；这里没有用分部署缓存也是由于Dcache我们测试过单次耗时在2ms-6ms之间，由于网络请求慢，会拖慢整个接入层的响应
问题
- 由于服务B经常无法实时同步到更新的数据，导致客户端多次请求到的策略，负载均衡到不同的服务B容器上，导致请求的策略不一致 例如：请求不到最新策略、先请求到最新策略然后又请求到过时的策略
问题定位
-
定位流程
-
直接打印服务B的ZK日志，确认ZK 监听端延时很高 [图片上传失败...image.png
-
通过web页面操作策略启停，通过zkClient实时查看zk数据是否实时写入,节点目录在BETA_TACTICS,新创建一条策略会在BETA_TACTICS生产一个子节点，根据操作，数据是实时写入的
cd /data/tools/zookeeper-3.4.11/bin;./zkCli.sh -server localhost:8888 get /com/tencent/grayOuter/config/BETA_TACTICS/d562178d23_0fabbd14-345c-44c6-ab7e-bc35c78a8cda_1image.png -
查看zk负载情况，发现ZK负载没异常
查看ZK的进程情况image.png
image.png查看ZK的内存情况
image.png
image.png -
直接打印服务B的ZK日志，确认ZK 监听端延时很高 [图片上传失败...
- /com/tencent/grayOuter/config/BETA_TACTICS 节点下面存储所有的策略节点，发现数据量非常大，根据其中一个node查看数据是很久一起用过之后废弃的策略，但ZK还存储着的，怀疑使用的ZK node永久模式，导致ZK Server需要watche的数据量较大
图片是删除历史数据之后的节点
image.png
查看某个子节点的详细数据：get /com/tencent/grayOuter/config/BETA_TACTICS/56ab4ccc4f_b6432b11-6198-4fbb-91ac-b52c928119b7_1
image.png
5.查看源码确认子节点是永久模式，只有主动删除的情况节点才会删除，在查看DB里面的历史记录，月20W条数据，故怀疑ZK服务端需要watche的节点量大，导致下游watcher监听不及时。
image.png
-
根据第4步的分析，考虑采用直接删除历史节点的方式操作验证想法（由于这些节点只是数据同步的作用，现在实时同步基本不可用，所以配置同步基本上都是定时JOB来进行加载的，删除节点对业务没有影响）
删除子节点 rmr /com/tencent/grayOuter/config/BETA_TACTICS create /com/tencent/grayOuter_test/BETA_TACTICS beta_tactics操作前的数据延时
image.png操作后，配置可以实时获取到
image.png
总结
使用ZK永久节点作为配置同步，需要考虑数据量的大小，若数据量大（上万），则需要考虑使用MQ中间件的方式，ZK不适合数据量大的配置同步
