ZooKeeper 的架构是怎样的？-Toy模板网

这篇具有很好参考价值的文章主要介绍了ZooKeeper 的架构是怎样的？。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

前言

本文隶属于专栏《大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见大数据技术体系

ZooKeeper 的架构是怎样的？

ZooKeeper 的架构图主要包含以下几个部分：

ZooKeeper Client：是 ZooKeeper 的客户端，可以连接到任意一个 ZooKeeper Server 上（除非 leaderServes 参数被显式设置，leader 不允许接受客户端连接）。客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接收响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断，客户端将自动尝试连接到另外的 ZooKeeper Server。
ZooKeeper Server：是 ZooKeeper 的服务端，可以组成一个集群来提供高可用的分布式协调服务。

Leader：是整个 ZooKeeper 集群工作机制中的核心。Leader 作为整个 ZooKeeper 集群的主节点，负责响应所有对 ZooKeeper 状态变更的请求。主要工作有：事务请求的唯一调度和处理，保障集群处理事务的顺序性。集群内各服务器的调度者。Leader 选举是 ZooKeeper 最重要的技术之一，也是保障分布式数据一致性的关键所在。
Follower：是 ZooKeeper 集群状态的跟随者。他的逻辑就比较简单。除了响应本服务器上的读请求外，follower 还要处理 leader 的提议，并在 leader 提交该提议时在本地也进行提交。另外需要注意的是，leader 和 follower 构成 ZooKeeper 集群的法定人数，也就是说，只有他们才参与新 leader 的选举、响应 leader 的提议。
Observer：服务器充当一个观察者的角色。如果 ZooKeeper 集群的读取负载很高，或者客户端多到跨机房，可以设置一些 observer 服务器，以提高读取的吞吐量。

Observer 和 Follower 比较相似，只有一些小区别：首先 observer 不属于法定人数，即不参加选举也不响应提议，也不参与写操作的“过半写成功”策略；其次是 observer 不需要将事务持久化到磁盘，一旦 observer 被重启，需要从 leader 重新同步整个名字空间。