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，数据同步