127、从zk集群启动到数据同步再到崩溃恢复的ZAB协议流程

zk集群启动的时候，进入恢复模式，选举一个leader出来，然后leader等待集群中过半的follower跟他进行数据同步，只要过半follower完成数据同步，接着就退出恢复模式，可以对外提供服务了

只要有超过一半的机器，认可你是leader，你就可以被选举为leader

3台机器组成了一个zk集群，启动的时候，只要有2台机器认可一个人是Leader，那么他就可以成为leader了

3台可以容忍不超过一半的机器宕机，1台

剩余的2台机器，只要2台机器都认可其中某台机器时leader，2台 > 一半，就可以选举出来一个leader了

zk的leader选举算法，我们可以在后面的zk核心源码剖析的时候

1台机器时没有办法自己选举自己的

5台机器，3台机器认可某个人是leader；可以允许2台机器宕机，3台机器，leader选举，只要是5台机器，一半2.5，3台机器都认可某个人是leader，此时3 > 2.5，过半，leader是可以选举出来的

2台机器，小于一半，没有办法选举新的leader出来了

当然还没完成同步的follower会自己去跟leader进行数据同步的

此时会进入消息广播模式

只有leader可以接受写请求，但是客户端可以随便连接leader或者follower，如果客户端连接到follower，follower会把写请求转发给leader

leader收到写请求，就把请求同步给所有的follower，过半follower都说收到了，就再发commit给所有的follower，让大家提交这个请求事务

如果突然leader宕机了，会进入恢复模式，重新选举一个leader，只要过半的机器都承认你是leader，就可以选举出来一个leader，所以zk很重要的一点是主要宕机的机器数量小于一半，他就可以正常工作

因为主要有过半的机器存活下来，就可以选举新的leader

新leader重新等待过半follower跟他同步，完了重新进入消息广播模式

2PC是什么，两阶段提交，Java架构里的分布式事务的课程，好好去看一下

集群启动：恢复模式，leader选举（过半机器选举机制） + 数据同步

消息写入：消息广播模式，leader采用2PC模式的过半写机制，给follower进行同步

崩溃恢复：恢复模式，leader/follower宕机，只要剩余机器超过一半，集群宕机不超过一半的机器，就可以选举新的leader，数据同步