很遗憾，没有一篇文章能讲清楚ZooKeeper

ZAB 广播 PROPOSAL

选举了 Leader 领导集群，Leader 接受到 Client 的请求以后，也可以协调 Follower 工作了。

那么如果 Client 很多的情况下，特别是这些客户端都是做读操作的时候，ZooKeeper 服务器如何处理如此多的请求呢?这里引入 Observer 的概念。

Observer 和 Follower 基本一致，对于非事务请求(读操作)，可以直接返回节点中的信息(数据从 Leader 中同步过来的)。

对于事务请求(写操作)，会转交给 Leader 做统一处理。Observer 的存在就是为了解决大量客户端读请求。

Observer 和 Follower 的区别是，Observer 不参与仲裁投票，选举 Leader。

Observer 加入 Leader 和 Follower 大家庭

总结

全文用了一个简单的例子讲 ZooKeeper 的主要特性和实现原理，最后做个总结。

ZooKeeper 被用来协调和管理分布式系统，发挥着重要的作用。分布式系统由于其特性，应用分布在不同的物理主机或者网络中。

为了让它们协同工作，ZooKeeper 中的 ZNode 成为统一协调的重要部分，客户端通过 Client 间接到服务端的 ZNode 上，监听 ZNode 数据的变化。

同时 ZNode 支持的持久，临时和顺序性，以及版本(Version)控制，这些特性支持了分布式事务和锁的功能。

如果说，每一个 ZooKeeperClient 对 Server 的写入操作都是一次事务的话，ZooKeeper 服务端维护了大量的事务，并且通过“分桶策略”来管理它们，保证了 Client 与 Server 端协调工作。

为了提高 Server 的可靠性，ZooKeeper 引入了 Server 集群的概念。通过仲裁机制选举 Leader 来领导其他 Follower。

事物都由 Leader 来处理，通过两段提交的方式对其他 Server 发起广播。为了增强对非事务请求的处理效率，ZooKeeper 加入了 Observer 来帮忙。

ZooKeeper 包含的内容远不止上面说的这些，由于篇幅的原因无法一一道来。

为了方便大家理解，文中将一些原理做了简化处理，希望有机会和大家做深入的探讨，咱们下次见。

作者：崔皓

简介：十六年开发和架构经验，曾担任过惠普武汉交付中心技术专家，需求分析师，项目经理，后在创业公司担任技术/产品经理。善于学习，乐于分享。目前专注于技术架构与研发管理。

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!