zookeeper的前世今生

背景

zookeeper的出现

分布式单点故障

提到zookeeper不得不提一下分布式系统中的单点故障:通常是分布式系统采用主从模式，就是一个主控机链接多个处理节点，主节点复制分发任务，从节点负责处理任务，当我们的主节点发生故障，整个系统就会瘫痪，这就是单点故障。

传统方式是采用一个备用节点，这个备用节点定期给当前主节点发送ping包，主节点收到ping包以后向备用节点发送回复Ack，当备用节点收到回复的时候就会认为当前主节点还活着，让他继续提供服务。如图：

如果出现网络问题，就会造成以下后果：

主节点没有挂，只是在回复时断网了，这样备用节点收不到回复，就认为主节点挂了，然后备用节点将他的Master实例启动，这样我们的分布式系统就有两个主节点，出现双master，这样从节点就会将它所做的一些事汇报给主节点一部分，从节点一部分，服务就会乱。为了防止这种情况所以引入了zookeeper，它不能避免网络故障，但是它能保证只有一个master。
引入zookeeper后，我们启动了两个主节点，“主节点A”和“主节点B”他们启动以后，都向zookeeper注册一个节点。我们假设“主节点A”所注册的节点是“master00001”，“主节点B”注册的节点是“master00002”，注册完以后进行选举，编号最小的节点将在选举中获胜，获得锁成为主节点，也就是我们的“主节点A”获得锁成为主节点，然后“主节点B”将被阻塞成为一个备用节点。

如果“主节点A”挂了，这时候他说注册的节点将自动被删除，zookeeper会自动感知节点的变化然后再次选举，这时候“主节点B”选举获胜。

“masterA”恢复后

如果主节点恢复了，他再次向zookeeper注册一个节点，这时候他注册的节点将会是“master00003”，zookeeper会感知节点变化再次发动选举这时候“主节点B”在选举中再次获胜继续担任“主节点”，“主节点A”会担任备用节点。

zookeeper名字的由来

关于zookeeper这个项目的名字，也有一个趣闻，在项目建立初期，考虑到之前很多项目都使用动物名字来命名的，雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家RaghuRamakrishnan开玩笑地说：“在这样下去，我们这儿就变成动物园了!”此话一出，大家纷纷表示就叫动物园管理员吧一一一因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好要用来进行分布式环境的协调一一于是，Zookeeper的名字也就由此诞生了。

zookeeper工作原理

zookeeper的角色

领导者（leader）:负责进行投票的发起和决议，更新系统状态
学习者（learner）：包括跟随者（follower）和观察者（observer），follower用于接收客户端请求并向客户端返回结果，在选主过程中参与投票
Observer：可以接收客户端连接，将写请求转发给leader，但observer不参与投票，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
客户端：请求发起方

• zookeeper的核心是原子广播，这个机制保证各个server之间的同步，实现这个机制的协议叫做Zab协议，Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
• 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都被在提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否被改变，每次一个leader被选出来，它会有一个新的epoch，标识当前属于哪个leader的通知时期。低32位用于递增计数。
• 每个Server在工作过程中有三种状态：
  　　　　LOOKING：当前Server不知道leader是谁，正在搜寻
  　　　　LEADING：当前Server即为选举出来的leader
  　　　　FOLLOWING：leader已经选举出来，当前Server与之同步

zookeeper节点数据操作流程

---

zookeeper leader选举