Zookeeper（分布式应用程序协调服务）

2022-03-25 09:46:17

1.简述

zookeeper，动物园管理者，动物饲养员。以下简称zk。
它是一个分布式一致性解决方案，为分布式应用提供分布式协调服务。
它开源、强大，得到了广泛的应用。Haddop，Storm都已经将zk作为核心组件，用于分布式协调。

2.集群角色

Leader，为客户端提供读写服务。

Follower，提供读服务，参与lerder选举。

Observer，只提供读服务。

每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻；
LEADING：当前Server即为选举出来的leader；
FOLLOWING：leader已经选举出来，当前Server与之同步。

3.功能

数据节点。ZooKeeper将所有数据存储在内存中，数据结构是一个树(ZNode Tree)。
会话。zk对外服务的默认端口是2181，客户端会与它建立长连接。
事件监听器。Watcher是zk的重要特性。用户可以在指定节点上注册一些watcher，当指定的事件触发后，用户得到通知。

4.ZAB协议

ZAB，Zookeeper Atomic Broadcast，zk原子广播。
zk并没有用Paxos算法，用的是自己的zkb。
主要思想是这样的。所有事务请求必须由leader协调。leader负责将客户端的事务请求转换为proposal，分发给所有follower，若超过半数的follower给出正确反馈，则leaser再向所有的follower发送commit消息。

4.1 zxid

ZooKeeper每一次的状态改变, 都对应着一个递增的Transaction id, 称为zxid。由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定早于zxid2发生。

对任意节点的增、删、改操作，都会导致Zookeeper状态发生改变, 从而导致zxid的值增加。

实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

5.Leader选举

通过投票来选举。投票是广播行为，投票格式为<sid,zxid>。

5.1投票变更策略

在没有leader或leader挂了之后，follower会将角色变更为looking，然后开始选举。
第一轮，大家都投自己。对于接收到的投票，采取如下whetherAccept()策略：

boolean whetherAccept(Vote vote){
	if(vote.zxid>zxid)
		return true;
	if(vote.zxid==zxid&&vote.sid>sid)
		return true;
	return false;
}

若返回true，认可该投票并广播。其他情况都坚持自己原有的投票。

5.2 统计投票

每轮投票结束后，开始统计得票。如果一台机器收到了超过半数的相同投票，记为voteA，那么voteA.sid即为新的leader。

6.过半存活即可用

一个zk集群如果要对外提供服务，那么集群中必须要有过半的机器正常工作且彼此之间通信正常。即“过半存活即可用”。

问：选leader时也用到了过半的思想，那么机器部署必须为奇数台么？

答：不是这样。根据leader选举策略，任意台都是可以的。

问：为什么推荐集群中的机器数为奇数个？

答：这是出于节省成本的考虑。因为“过半存活才可用”的思想，你部署了10台，挂掉5台就不能用了。而你部署9台，也是挂掉5台就不能用了。

码农公寓