对于ZooKeeper中的ZAB协议，这样的理解是否正确？
问题描述
ZooKeeper中的ZAB协议主要分为消息广播和崩溃恢复两个阶段。
正常情况下ZAB是这样运行的：
所有的事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则称为Follower服务器。
Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。
之后Leader服务器需要等待所有的Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求将其前一个Proposal进行提交。
——《从Paxos到ZooKeeper 分布式一致性原理与实践》
以下是本人对于ZAB协议的理解，不知是否正确。
一个Leader，多个Follower，Leader处理客户端请求，并发送Proposal给所有的Follower，得到超过半数的Ack就发送commit消息通知Follower进行提交。
Leader可能会崩溃。如果在发送完commit消息后崩溃，之前发送给Follower的Proposal仍然会提交，以达到Follower和Leader的数据一致性。如果在发完Proposal还没发送commit时崩溃，则在该Leader重新加入集群后会被要求删除该Proposal。
Leader崩溃了，需要选举出新的Leader。选举出集群中拥有最高Proposal编号（即ZXID）的Follower，因为其已经提交最新的Proposal，可以保证该Follower的状态是集群中最新的。
开心地开始正常的工作。
原来崩溃的老干部旧Leader恢复工作，收到当前小鲜肉Leader的广播消息，知道世道变了，开始和新Leader数据同步。原来未提交的Proposal的ZXID比当前的小，丢弃。然后同步当前Leader任期内所有已经提交的Proposal。
数据同步完成后，老干部成为了真正的Follower，集群又开始正常工作。
以下是一些关于ZAB协议的疑问：
无论哪个节点收到客户端请求，都需要转发给Leader，Leader的压力会不会挺大的？
老干部旧Leader从崩溃状态中恢复，丢弃未提交的Proposal可以理解。同时需要同步当前小鲜肉Leader任期内所有提交的Proposal，是否可以理解为Leader需要保存其任期内所有成功的Proposal？如果集群一直正常运行，Leader在存储方面是否会有压力。
加入一个全新的节点，肯定需要和当前Leader做同步。如果在同步过程中，当前的Leader崩溃，则该节点需要和新的Leader进行同步，是否意味着新的Leader需要保存整个集群从开始运行到当前所有的Proposal？（和第2点是递进关系）
请各位大佬帮忙解答，给dalao递柠檬茶。
是的。follower会分担读请求，但不能分担写请求(事务) leader-follower模式提高了可用性(follower副本兜底)，但不能提高tps处理,且随着节点增多每个事务请求需要同步的follower节点越多，这样每个事务等待时间会越长。
第一个问题：是的，Follower可能存的是一个任期内所有Proposal的子集，第二个问题，是的，所以zk不适合存储数据只适合存简单的配置等元数据，
是的
这篇关于对于ZooKeeper中的ZAB协议，这样的理解是否正确？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
