Zookeeper实现分布式锁和选主

Zookeeper可以用来实现Distributed lock(分布式锁)和leader election(选主)。

分布式锁和选主虽然用在不同的场景,但是2者的机制是相同的。

Zookeeper官方文档上给出了一个recipes,介绍了如何实现分布式锁和选主,2种实现说明的步骤和风格完全不一样,但是本质是一样的。

这里先翻译一下recipes对2者的说明。

获得锁的步骤:

  • 1.调用create(),以”locknode/lock-“作为路径名,并且设置sequence和ephemeral标志
  • 2.在锁节点上,也即”locknode“,调用getChildren(),但不带watch标志
  • 3.如果在步骤1中创建的路径名具有最小的后缀,则客户端获得锁,客户端退出协议
  • 4.如果客户端在步骤3中没有获得锁,则客户端调用exist(),带上watch标志,在比步骤1创建的路径名小的路径上。
  • 5.如果不存在,则跳到步骤2。如果存在存在,则等待路径名变化的通知,再跳转到步骤2。

Leader Election的伪代码:
假设ELECTION是应用选择的路径名。应用要变成leader,执行以下步骤:
- 1.用”ELECTION/n_”作为路径名创建一个znode,设置SEQUENCE和EPHEMERAL2个标志。成功建立的znode,我们叫它做z。
- 2.”ELECTION”下所有的znode的集合我们称为C,i是z的序列号。
- 3.watch节点”ELECTION/n_j的变化,j是满足j < i 和 n_j 是C中的一个znode这2个条件的最大序列号。

2者都是基于Zookeeper具有SEQUENCE和EPHEMERAL两个特性。所有的客户端都在同一个节点下创建子节点,序列号最小的客户端,获得锁或者称为leader,其他客户端watch比自己创建的节点序列号小的那个节点,一旦有变化再判断自己创建的节点是不是最小的,如果是自己获得锁或者称为leader。

发布了32 篇原创文章 · 获赞 14 · 访问量 7万+
展开阅读全文

zookeeper流程的疑问

10-08

2.1 选主流程 当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种:一种是基于basic paxos实现的,另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程: 1 .选举线程由当前Server发起选举的线程担任,其主要功能是对投票结果进行统计,并选出推荐的Server; 2 .选举线程首先向所有Server发起一次询问(包括自己); 3 .选举线程收到回复后,验证是否是自己发起的询问(验证zxid是否一致),然后获取对方的id(myid),并存储到当前询问对象列表中,最后获取对方提议的leader相关信息(id,zxid),并将这些信息存储到当次选举的投票记录表中; 4. 收到所有Server回复以后,就计算出zxid最大的那个Server,并将这个Server相关信息设置成下一次要投票的Server; 5. 线程将当前zxid最大的Server设置为当前Server要推荐的Leader,如果此时获胜的Server获得n/2 + 1的Server票数, 设置当前推荐的leader为获胜的Server,将根据获胜的Server相关信息设置自己的状态,否则,继续这个过程,直到leader被选举出来。 通过流程分析我们可以得出:要使Leader获得多数Server的支持,则Server总数必须是奇数2n+1,且存活的Server的数目不得少于n+1. 每个Server启动后都会重复以上流程。在恢复模式下,如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息,zk会记录事务日志并定期进行快照,方便在恢复时进行状态恢复。选主的具体流程图如下所示: **问题如下:** 1、"当前Server发起选举的线程担任",当前Server是哪一个?还是所有的 2、”获取对方提议的leader相关信息(id,zxid)“ 对方是怎么提议的?此时每个机器只认识自己id,难道都是提自己?因为不是选村长,大家都认识对方能力 实在不明白,求教 问答

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览