ZK之Watcher模式假死

导语

近期专项定位某个服务的用户反馈，其中有个业务使用zookeeper进行配置同步，但发现延时1——20分钟不等，导致数据加载不及时，引起一系列问题。

服务架构

image.png

• 接入层负责接入大量的客户端请求，对实时性要求高
• 由于接入层实时性要求高，服务B配置信息均加载到内存，变更的情况通过ZK进行实时通知，然后从MDB加载变更数据；这里没有用分部署缓存也是由于Dcache我们测试过单次耗时在2ms-6ms之间，由于网络请求慢，会拖慢整个接入层的响应

问题

• 由于服务B经常无法实时同步到更新的数据，导致客户端多次请求到的策略，负载均衡到不同的服务B容器上，导致请求的策略不一致 例如：请求不到最新策略、先请求到最新策略然后又请求到过时的策略

问题定位

• 定位流程

  1. 直接打印服务B的ZK日志，确认ZK 监听端延时很高 [图片上传失败...
     image.png

  2. 通过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_1
     
     

     image.png

  3. 查看zk负载情况，发现ZK负载没异常
     查看ZK的进程情况

     image.png
  image.png

  查看ZK的内存情况

  image.png
  
  
  image.png

4. /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

6. 根据第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不适合数据量大的配置同步