对于ZooKeeper中的ZAB协议，这样的理解是否正确？

Question

ZooKeeper中的ZAB协议主要分为消息广播和崩溃恢复两个阶段。

正常情况下ZAB是这样运行的：

所有的事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则称为Follower服务器。

Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。

之后Leader服务器需要等待所有的Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求将其前一个Proposal进行提交。

——《从Paxos到ZooKeeper 分布式一致性原理与实践》

---

以下是本人对于ZAB协议的理解，不知是否正确。

1. 一个Leader，多个Follower，Leader处理客户端请求，并发送Proposal给所有的Follower，得到超过半数的Ack就发送commit消息通知Follower进行提交。

2. Leader可能会崩溃。如果在发送完commit消息后崩溃，之前发送给Follower的Proposal仍然会提交，以达到Follower和Leader的数据一致性。如果在发完Proposal还没发送commit时崩溃，则在该Leader重新加入集群后会被要求删除该Proposal。

3. Leader崩溃了，需要选举出新的Leader。选举出集群中拥有最高Proposal编号（即ZXID）的Follower，因为其已经提交最新的Proposal，可以保证该Follower的状态是集群中最新的。

4. 开心地开始正常的工作。

5. 原来崩溃的老干部旧Leader恢复工作，收到当前小鲜肉Leader的广播消息，知道世道变了，开始和新Leader数据同步。原来未提交的Proposal的ZXID比当前的小，丢弃。然后同步当前Leader任期内所有已经提交的Proposal。

6. 数据同步完成后，老干部成为了真正的Follower，集群又开始正常工作。

---

以下是一些关于ZAB协议的疑问：

1. 无论哪个节点收到客户端请求，都需要转发给Leader，Leader的压力会不会挺大的？

2. 老干部旧Leader从崩溃状态中恢复，丢弃未提交的Proposal可以理解。同时需要同步当前小鲜肉Leader任期内所有提交的Proposal，是否可以理解为Leader需要保存其任期内所有成功的Proposal？如果集群一直正常运行，Leader在存储方面是否会有压力。

3. 加入一个全新的节点，肯定需要和当前Leader做同步。如果在同步过程中，当前的Leader崩溃，则该节点需要和新的Leader进行同步，是否意味着新的Leader需要保存整个集群从开始运行到当前所有的Proposal？（和第2点是递进关系）

---

请各位大佬帮忙解答，给dalao递柠檬茶。

Answer 1

1. 是的。follower会分担读请求，但不能分担写请求(事务) leader-follower模式提高了可用性(follower副本兜底)，但不能提高tps处理,且随着节点增多每个事务请求需要同步的follower节点越多，这样每个事务等待时间会越长。

2. 第一个问题：是的，Follower可能存的是一个任期内所有Proposal的子集，第二个问题，是的，所以zk不适合存储数据只适合存简单的配置等元数据，

3. 是的