Zookeeper 服务器角色

Zookeeper 服务器角色

Leader

Leader 服务器是 zookeeper 集群工作的核心，其主要工作有以下两个：

1. 事务请求的唯一调度和处理者，保证集群事务处理的顺序性；
2. 集群内部各服务器的调度者

Leader 处理请求的过程：

zookeeper使用责任链模式来处理客户端的请求，Leader 服务器的请求处理链如下：

可以看到，从 prepRequestProcessor 到 FinalRequestProcessor 前后一共7个请求处理器组成了 Leader 服务器的请求处理链

1. PrepRequestProcessor

   请求预处理器，也是 leader 服务器中的第一个请求处理器。在 zookeeper 中，那些会改变服务器状态的请求成为事务请求（创建节点、更新数据、删除节点、创建会话等），PrepRequestProcessor 能够识别出当前请求是否为事务请求。

   对于事务请求：

   ​ PrepRequestProcessor 会对其进行一系列预处理，如创建请求事务头、事务体、会话检查、ACL检查和版本检查等。

2. ProposalRequestProcessor

   事务投票处理器，也是 leader 服务器事务处理请求的发起者。

   对于非事务请求，ProposalRequestProcessor 会直接将请求转发到 CommitProcessor 处理器，不再做任何处理；

   对于事务请求，处理器将请求转发到 CommitProcessor 外，还会根据请求类型创建对应的 Proposal 提议，并发送给所有的 Follower 服务器来发起一次集群内的事务投票。同时，ProposalRequestProcessor 还会将事务请求交付给 SyncRequestProcessor 进行事务日志的记录。

3. SyncRequestProcessor

   事务日志记录处理器，用来将事务请求记录到事务日志文件中，同时会触发 zookeeper 进行数据快照。

4. AckRequestProcessor

   负责在 SyncRequestProcessor 完成事务日志记录后，向Proposal 的投票收集器发送ACK反馈，以通知投票收集器当前服务器已经完成对该 proposal 的事务日志记录

5. CommitProcessor

   事务提交处理器。

   对于非事务请求，该处理器会直接将其交付给下一级处理器处理；

   对于事务请求，会等待集群中内 针对该 Proposal 的投票知道改 Proposal 可被提交，利用 CommitProcessor ，每个服务器都可以很好地控制事务请求的顺序处理

6. ToBeCommitProcessor

   该处理器有一个 toBeApplied 队列，用来存储那些已经被 CommitProcessor 处理过的可被提交的 Proposal。其会将这些请求交付给 FinalRequestProcessor 处理器请求，待其处理完后，再将其从 toBeApplied 队列中移除。

7. FinalRequestProcessor

   用来进行客户端请求返回之前的操作，包括创建客户端请求的响应。

   针对事务请求，该处理器还会负责将事务应用到内存事务中。

Follower

Follower 服务器是 Zookeeper 集群状态的跟随者，其主要工作有以下三个：

1. 处理客户端的非事务性请求（读取数据），转发事务服务器给Leader 服务器
2. 参与事务请求Proposal 的投票
3. 参与 Leader 选举投票

和 Leader 一样，Follower 也采用了责任链模式组装的请求处理链来处理每一个客户端请求，由于不需要对事务请求的投票处理，因此 Follower 的请求处理链会相对简单，其处理链如下：

和 Leader 服务器处理请求链最大的不同点在于，Follower 服务器第一个处理器换成了 FollowerRequestProcessor 处理器，同时由于不需要处理事务请求的投票，因此也没有了 ProposalRequestProcessor 处理器。

1. FollowerRequestProcessor

   用于识别当前请求是否为事务请求，若是，则转发给 Leader 服务器处理，Leader 服务器在接收到这个事务请求后，就会将其提交到请求处理链，按照正常事务进行处理。

2. SendAckRequestProcessor

   其承担了事务日志记录反馈的角色，在完成事务日志记录后，会向 Leader 服务器发送 Ack 消息以表明自己完成了事务日志的记录工作

Observer

Observer 是 zookeeper 自3.3.0版本开始引入的一个全新的服务器角色。从字面意思看，该服务器充当了一个观察者的角色——观察zookeeper集群的最新状态变化并将这些状态变更同步过来。

Observer 服务器在工作原理上和 Follower 基本是一致的，对于非事务请求，都可以进行独立的处理；对于事务请求，则会转发给 Leader 服务器进行处理。

和 Follower 的区别在于，Observer 不参与任何形式的投票，包括事务请求 Proposal 的投票和 Leader 选举投票。简单地讲，Observer 只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的读能力。

另外，Observer 的请求处理链路和 Follower 服务器也非常接近，其处理链如下：

另外需要注意的一点是，虽然图中可以看到，Observer 服务器初始化阶段会将 SyncRequestProcessor 处理器也组装上去，但是在实际运行中， Leader 服务器不会将事务请求的投票发送给 Observer 服务器。