zk 导致gRPC负载不均衡.pdf

从提供的文件内容来看，该文档主要探讨了由Zookeeper（ZK）引起的gRPC服务请求负载不均衡问题。分析从xueqiu-grpc的调用原理开始，深入探讨了问题的现象、原因分析、测试验证过程以及最终的解决方案。 知识点一：xueqiu-grpc调用原理 xueqiu-grpc调用原理涉及gRPC服务发现机制，在文档中提出了xueqiu使用gRPC进行服务间通信时，服务的发现与调用是如何进行的。gRPC是一种现代的开源高性能RPC框架，它允许客户端直接调用不同机器上的服务，就像调用本地对象一样简单。 知识点二：服务请求不平衡现象 文档指出在某些情况下，服务请求分布不均，出现负载不均衡的现象。这通常表现为某些服务实例的请求量远高于其他实例，这可能导致部分服务实例过载，而其他实例则相对空闲。 知识点三：问题分析及猜想验证 文档中列举了三个猜想来解释服务请求不平衡的原因。猜想一怀疑是Zookeeper的负载过高导致连接断开，但通过验证发现连接并无异常，但与Zookeeper相关的日志异常增多，显示了大量zkWatch事件的触发。 知识点四：zkWatch事件影响 zkWatch事件是Zookeeper中一个重要的特性，它允许客户端监听一个节点的变化，并在节点发生变更时得到通知。在文档中，通过监听到的zkWatch事件，发现了服务列表没有发生变化，而是zk中的service节点下的任何改动都会触发hearbeatEvent事件，进而引发大规模的通信交互。 知识点五：服务列表刷新导致的问题 文档分析了Zookeeper的watch机制导致本地nameResolvers刷新时，会导致服务列表变更，每次nameResolvers刷新会创建新的Picker对象，并且会首选请求列表中的第一台实例。由于上游服务几乎同时刷新，这导致了大部分的请求集中到了同一台服务实例上，从而产生了负载不均衡。 知识点六：负载均衡算法与节点问题 文档还讨论了负载均衡算法是否是导致请求不平衡的原因之一。然而，问题似乎出现在nameResolvers刷新时，总是对相同的节点产生请求。 知识点七：代码分析与问题解决 文档最后提到了针对这一问题的代码修复。gRPC社区已经开始关注并修复了相关的问题。文档中提到了一个特定的GitHub pull request（PR），它针对grpc-java项目进行了修复。 知识点八：版本更新信息 在文档的提供了修复涉及到的gRPC版本信息，分别是1.9.0和1.15.1版本，这暗示了解决方案已经被集成到这些特定版本中。 总结来说，该文档全面分析了由于Zookeeper集群中的watch机制和Zookeeper节点变化导致的gRPC服务负载不均衡问题，并通过猜想验证、问题分析、测试环境演示以及代码修正等步骤，最终找到了问题的根源并给出了解决方案。这些内容对于理解gRPC服务发现机制、Zookeeper的使用以及负载均衡策略的实现都有重要的参考价值。