用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。

时间: 2024-08-31 10:26:57

用Zookeeper实现分布式锁和选主的相关文章

Zookeeper,etcd,consul内部机制和分布式锁和选主实现的比较

我的另外3篇文章分别介绍了Zookeeper,etcd,consul是如何实现分布式锁和选主的.本文想比较一下Zookeeper.etcd.consul内部机制有哪些不同,他们实现锁和选主的方式相同和不同. Zookeeper提供了临时节点,sequence,和变更通知.利用Zookeeper的这3个特性实现了按照sequence的顺序依次获取锁和成为主. etcd没有临时节点的概念,但是通过租约的方式提供了类似的功能.etcd没有sequence的概念,但是提供了全局递增的序列号revisio

用Etcd实现分布式锁和选主

Etcd的v3版本官方client里有一个concurrency的包,里面实现了分布式锁和选主.本文分析一下它是如何实现的. 先贴一下锁的code (https://github.com/coreos/etcd/blob/master/clientv3/concurrency/mutex.go#L26). 在code中注释介绍了具体的实现. //m.pfx是前缀,比如"service/lock/" //s.Lease()是一个64位的整数值,etcd v3引入了lease(租约)的概念

基于Zookeeper的分布式锁

这篇文章只需要你10分钟的时间. 实现分布式锁目前有三种流行方案,分别为基于数据库.Redis.Zookeeper的方案,其中前两种方案网络上有很多资料可以参考,本文不做展开.我们来看下使用Zookeeper如何实现分布式锁. 什么是Zookeeper? Zookeeper(业界简称zk)是一种提供配置管理.分布式协同以及命名的中心化服务,这些提供的功能都是分布式系统中非常底层且必不可少的基本功能,但是如果自己实现这些功能而且要达到高吞吐.低延迟同时还要保持一致性和可用性,实际上非常困难.因此z

基于ZooKeeper的分布式锁和队列

在分布式系统中,往往需要一些分布式同步原语来做一些协同工作,上一篇文章介绍了Zookeeper的基本原理,本文介绍下基于Zookeeper的Lock和Queue的实现,主要代码都来自Zookeeper的官方recipe. 锁(Lock) 完全分布式锁是全局同步的,这意味着在任何时刻没有两个客户端会同时认为它们都拥有相同的锁,使用 Zookeeper 可以实现分布式锁,需要首先定义一个锁节点(lock root node). 需要获得锁的客户端按照以下步骤来获取锁: 保证锁节点(lock root

基于ZooKeeper实现分布式锁

ZooKeeper 保证了数据的强一致性,  zk集群中任意节点(一个zkServer)上的相同znode下的数据一定是相同的.使用zookeeper可以非常简单的实现分布式锁, 其基本逻辑如下: 客户端调用create()方法创建名为"locknode/lock"的节点,需要注意的是,这里节点的创建类型需要设置为EPHEMERAL_SEQUENTIAL. 客户端调用getChildren("lock")方法来获取所有已经创建的lock节点的子节点,同时在这个节点上

ZooKeeper的分布式锁和队列实现实例教程

在分布式系统中,往往需要一些分布式同步原语来做一些协同工作,上一篇文章介绍了Zookeeper的基本原理,本文介绍下基于Zookeeper的Lock和Queue的实现,主要代码都来自Zookeeper的官方recipe. 锁(Lock) 完全分布式锁是全局同步的,这意味着在任何时刻没有两个客户端会同时认为它们都拥有相同的锁,使用 Zookeeper 可以实现分布式锁,需要首先定义一个锁节点(lock root node). 需要获得锁的客户端按照以下步骤来获取锁:     保证锁节点(lock

用Consul实现选主

Consul实现leader election的过程是这样的过程(这个过程主要翻译自Consul的文档): 1.所有客户端都竞争操作一个key,比如这个key是service//leader. 2.所有客户端创建一个session,创建成功后每个客户端都会获得一个sessionid. 3.所有想成为leader的客户端都试图去更新这个key,并且所有客户端都acquire=这个请求参数.acquire是consul在kv存储的api上扩展的功能.acquire的意思是获取更新这个key的锁,se

ZooKeeper 笔记(6) 分布式锁

目前分布式锁,比较成熟.主流的方案有基于redis及基于zookeeper的二种方案. 大体来讲,基于redis的分布式锁核心指令为SETNX,即如果目标key存在,写入缓存失败返回0,反之如果目标key不存在,写入缓存成功返回1,通过区分这二个不同的返回值,可以认为SETNX成功即为获得了锁. redis分布式锁,看上去很简单,但其实要考虑周全,并不容易,网上有一篇文章讨论得很详细:http://blog.csdn.net/ugg/article/details/41894947/,有兴趣的可

zookeeper分布式锁避免羊群效应(Herd Effect)

本文主要讲述在使用ZooKeeper进行分布式锁的实现过程中,如何有效的避免"羊群效应( herd effect)"的出现. 一般的分布式锁实现 这里简单的讲下一般的分布式锁如何实现.具体的代码实现可以在这里看到:https://svn.apache.org/repos/asf/zookeeper/trunk/src/recipes/lock/ 在之前的<ZooKeepe数据模型>一文中提到过,zookeeper中节点的创建类型有4类,这里我们重点关注下临时顺序节点.这种类