Zookeeper 写入和选举原理深入分析及演示

上篇分析了ZK的搭建和基本操作，此次我们深入分析其原理，包括扩展性、可用性、一致性、可靠性、时序性等等。

1、扩展性原理：

此处原理参考：参考原理 

2、可靠性原理：

3、客户端数据写入过程：

 3.1、ClientA发起创建节点，数据传给FollowerA从节点,FollowerA没有创建权限，随后把数据经过2create(ooxx),传递给Leader主节点，主节点给其返回over-ok。

3.2、之后主节点开始两阶段提交，首先主节点向所有从节点发送log日志，如4-1:log，每个从节点均给主节点返回OK。

3.3、然后进入第二阶段，主节点向所有从节点以广播的形式写入数据，通知过半（正常情况下都会全部送到），如4-2 write ,成功后各从节点返回OK。

3.4、此后每个节点都有最新的数据，无论客户端请求到哪台服务器，都可以获取到最新的数据。

3.5、 这是在完美情况下的服务状态，如果同步到从节点数据没有过半，或者没有同步等情况，客户端下次取不到数据吗？这类特殊问题我们后期会详细分析。

4、leader挂了之后重新选举的策略：假设刚开始node4是leader突然挂了，剩下三台服务器迅速选出一个新的leader。

 

4.1、第一次启动集群时，所有节点的zxid都是零，参考myid，谁的myid大，谁就被选成leader。

4.2、leader挂了后，从节点开始选新的leader，此时谁的zxid大，谁就被选成leader，如果大家的zxid都一样大，这时就参考谁的myid大，谁就被选成leader。

4.3、比如node3首先发现leader挂了，就会通知node2、node1,由于node3的zxid是7，小于node1    、node2的zxid 8,被驳回。此时node1、node2也迅速给其他节点发起投票，由于他们俩的zxid都是8，只能参考myid，因此选node2为新的leader。

5、服务器命令演示leader选举过程：

5.1、刚开始四台服务器，node4是leader，其余都是从节点。

node4节点挂了：

其余三台迅速选出了新的leader是node3:

 此时如果node3挂了，还剩两台服务，数量没有过半，不能选出新的leader，即两台服务都会变成不可用状态。

其余服务状态： 

node2;

node1:

 但是服务的进程还是有的，只是停止了对外提供服务：

 此时启动node4,集群就立刻变成可用状态:

 并且node2变成了主节点:

 到此，ZK写入和选举策略的原理分享完毕，下一篇我们分析ZK监听的原理和实战，敬请期待！