zk个人入门学习总结

ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。


zk的核心算法为ZAB(原子消息广播协议)，与Paxos不同，这是一种特别为zk设计的崩溃可恢复的原子消息广播算法,ZAB的架构可见下文：
https://distributedalgorithm.wordpress.com/2015/06/20/architecture-of-zab-zookeeper-atomic-broadcast-protocol/


而ZAB的核心如下：
所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交


**zab协议包括两个基本模式：消息广播以及崩溃恢复**


*消息广播流程示意图如下：*
（图片来自从Paxos到zk）


正如图中所示，部署zk集群至少需要有三个节点，否则zab就没要办法实现，实际上为了保证选举顺利，通常采用奇数个节点


*崩溃恢复：*

一旦Leader服务器出现崩溃，或者由于网络原因导致Leader服务器失去了过半Follower的联系，那么就会进入崩溃恢复模式，并且恢复后需要一个新的leader，因此zab协议需要一个高效的选举方案

简述领导选举过程

首先服务器将自身状态转换为looking，并向集群中所有的服务器发起投票（myid,zxid）
接收其他服务器发送的投票，并进行处理，按照zxid最大的作为leader，如果相同按照myid最大的作为leader，更新投票信息，再次向集群发送投票
统计投票结果，超过半数以上的投票即为leader
如果leader是自己，就把自己的状态变更为leading，否则变为follwing