zookeeper__leader选举——翻译官方recipes文档

zookeeper-3.4.6/docs/recipes.html

Leader Election

A simple way of doing leader election with ZooKeeper is to use the SEQUENCE|EPHEMERAL flags when creating znodes that represent "proposals" of clients. The idea is to have a znode, say "/election", such that each znode creates a child znode "/election/n_" with both flags SEQUENCE|EPHEMERAL. With the sequence flag, ZooKeeper automatically appends a sequence number that is greater that any one previously appended to a child of "/election". The process that created the znode with the smallest appended sequence number is the leader.

That's not all, though. It is important to watch for failures of the leader, so that a new client arises as the new leader in the case the current leader fails. A trivial solution is to have all application processes watching upon the current smallest znode, and checking if they are the new leader when the smallest znode goes away (note that the smallest znode will go away if the leader fails because the node is ephemeral). But this causes a herd effect: upon of failure of the current leader, all other processes receive a notification, and execute getChildren on "/election" to obtain the current list of children of "/election". If the number of clients is large, it causes a spike on the number of operations that ZooKeeper servers have to process. To avoid the herd effect, it is sufficient to watch for the next znode down on the sequence of znodes. If a client receives a notification that the znode it is watching is gone, then it becomes the new leader in the case that there is no smaller znode. Note that this avoids the herd effect by not having all clients watching the same znode.

Here's the pseudo code:

Let ELECTION be a path of choice of the application. To volunteer to be a leader:

1. Create znode z with path "ELECTION/n_" with both SEQUENCE and EPHEMERAL flags;

2. Let C be the children of "ELECTION", and i be the sequence number of z;

3. Watch for changes on "ELECTION/n_j", where j is the largest sequence number such that j < i and n_j is a znode in C;

Upon receiving a notification of znode deletion:

1. Let C be the new set of children of ELECTION;

2. If z is the smallest node in C, then execute leader procedure;

3. Otherwise, watch for changes on "ELECTION/n_j", where j is the largest sequence number such that j < i and n_j is a znode in C;

Note that the znode having no preceding znode on the list of children does not imply that the creator of this znode is aware that it is the current leader. Applications may consider creating a separate znode to acknowledge that the leader has executed the leader procedure.

 

---------------------------------------------------------------------------------------------------------

上述的实现是有原java版本的。这个实现和我直观的想法不太一样，考虑得比较全面（特别是很多人频繁竞选时的惊群效应）

 

一个基于ZooKeeper的 简单的leader选举办法是使用 SEQUENCE|EPHEMERAL标志创建znode，用它来标记客户端候选人.思路是：

有一个znode如"/election",每一个znode创建带SEQUENCE|EPHEMERAL标志的子znode "/election/n_".因为使用SEQUENCE标志，ZooKeeper自增znode的序号，每次追加在"/election"最大子节点后面，即比前面任何请求的序号都大，哪些创建具有最小序号的znode的进程即为leader。

尽管如此，但不全然这么简单，监控leader节点失败是非常重要的。因此，当当前Leader失效，一个连接的客户端成为新Leader。一个简易的解决方案是所有进程都去监控当前最小的znode，并检查它，当前最小znode被删除时，自己是否是新Leader。（当leader失效时，由于EPHEMERAL特性，其相应的znode会被删除）。但这会产生一个"惊群"现象（参见早起Linux的epoll惊群）：当当前leader失效，其他所有的进程都被唤醒，并且在"/election"节点上执行getChildren来获得"/elcection"当前子节点列表.如果连接的客户端很多，ZooKeeper Server将较耗时。为了避免"惊群",是监控集群中比自己的小的最大的znode。（举例：

1,2,3,4,5；当前节点znode=4，那么4应该监控的是节点3，而不是最小节点1），这样就被避免了所有进程都监控最小节点。

伪代码如下：

设ELECTION 是应用选定的路径，所有候选人要竞选Leader：

 

1. 创建zonde z ，其对应路径为 "ELECTION/n_"  创建标志（临时EPHEMERAL 、有序SEQUENCE ） ，
2. 设置C为"ELECTION"的子节点，而i为节点z（第一步创建节点成功时，会返回序号）
3. 在节点"ELECTION/n_j"上设置监控，且j满足j= MAX({k|k<i,n_k ∈C}),即j是比i小但最接近i的节点，如果不存在这样的节点，那么当前节点i就是leader了

当收到znode被删除时的通知消息,

 

1. 设C是最新的 "ELECTION"子节点集合
2. 如果z是最小节点，那么z是leader，执行相应逻辑
3. 否则，监控 "ELECTION/n_j"变化，同上 j= MAX({k|k<i,n_k ∈C})