视频链接：ZK集群服务节点角色、状态以及数据存储

ZK集群服务节点角色

ZK集群中的 server 分为三种角色：leader, follower, observer。

那么角色是在哪配置定义的呢？首先我们需要打开zk集群的配置文件，目录为：zk解压目录/zookeeper/conf/zoo.cfg，我们搭建配置的节点信息如下：

• server.1=localhost:2287:3387
• server.2=localhost:2288:3388
• server.3=localhost:2289:3389
• server.4=localhost:2290:3390:observer

下面我们用一张图来总结下ZK集群节点中leader, follower, observer 角色的作用

1. 事务请求的唯一处理者，保证集群事务处理的顺序性，它会将每个状态更新请求进行顺序管理，以便保证整个集群内部消息处理的 FIFO，遵循了顺序一致性（Sequential Consistency）。
2. 集群内部各服务器的调度者，负责响应集群的所有对Zookeeper数据状态变更的请求。leader 内部维护单调递增的 Zxid（ZooKeeper Transaction Id），针对客户端连接，断开连接，节点的写操作都会分配一个全局唯一的Zxid，同时这些操作是原子性的，并且是严格顺序性的，遵循ZAB原子广播一致性协议完成事务（transaction）操作。如果客户端有些操作，都会被 follower 统一转发给leader处理，然后leader会下发提案让follower投票，如果投票超过半数，则提交事务并通知follower和observer。
3. leader内部维护 session ，来自客户端的连接和断开连接，都会被统一follower 或 observer 转发给leader处理。

1. 处理客户端非事务请求、转发事务请求给 leader 服务器；
2. 参与事务请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案， 要求 Follower 投票）；
3. 参与 Leader 选举的投票 。

observer 是 zookeeper3.3 开始引入的一个全新的服务器 角色，从字面来理解，该角色充当了观察者的角色。 观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。observer 的工作原理与 follower 角色基本一致，而它和 follower 角色唯一的不同 在于 observer 不参与任何形式的投票，包括事务请求 Proposal的投票和leader选举的投票。简单来说，observer 服务器只提供非事物请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事物处理的能力 。相当于对zk集群完成了水平扩展。

ZK集群服务节点状态

Zookeeper 的存储

zookeeper中的znode数据都是在内存中优先维护和提供读服务，当事务被提交以及最终提交都会持久化到磁盘的日志文件中。

不断分享开发过程用到的技术和面试经常被问到的问题，如果您也对IT技术比较感兴趣可以「关注」我