协调中心性能大对比：zookeeper是如何解决负载均衡问题的

作为分布式系统的一个长久话题，协调中心的性能是一个很有意思的突破口。

作为java的分布式协调中心，常见的有zookeeper，redis ，memcache等全局性功能的组件，也有MySQL，mongoDB之类的数据库形持久存储。

两者之间的区别是显而易见的，全局功能组件更注重功能性，比如数据的全局一致性，方便调度等等。但是因为采用了类似树状的节点结构，每一个节点可以存储的数据量就有了上限，一般为1M。

而持久数据库存储的话，顾名思义，就是采用数据库形式进行存储，非常持久，但是作为协调中心的功能性层面就会有所不足。

那么这篇文章我们来仔细聊一聊关于zookeeper你不知道的二三事~

zookeeper的工作原理如图所示：

事实上，一个zookeeper就像一个管理员，管理者下方多个follower。

跟nginx不同的是，nginx是在服务器端口进行负载均衡的。

zookeeper则是在客户端进行负载均衡的。

使用zookeeper实现负载均衡只需要两个步骤就可以实现：
第一步是衡量状态--找出最适合处理这项工作的服务器以及衡量下属服务器的状态
第二步是算法层面--对应一个最适合的算法

我们来一起看看第一步——衡量下端服务器的状态该如何实现：因为zookeeper是一个树状的存储结构，不难想到可以通过增加节点的方式来进行下端的管理。

我们如果把一个临时节点当作一个服务器，用来记录这台服务器的状态。
那么创造一个这样的节点，就意味着有一台服务器上线了。
相对的，删除这样的一个节点就意味着一台服务器的下线。
而统计、记录结点的数量，就可以做到记录服务器状态的一个作用。

如果我们把这些节点都连接到一个父级server上，一个简单的负载均衡模型的第一步：平台状态的搭建就建立好了。

剩下的就是算法层面的技术问题，我们可以交给我其他的回答。

你还有什么想知道的，欢迎评论区留言点赞收藏，我们下期见~