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

我的另外3篇文章分别介绍了Zookeeper,etcd,consul是如何实现分布式锁和选主的。本文想比较一下Zookeeper、etcd、consul内部机制有哪些不同,他们实现锁和选主的方式相同和不同。

Zookeeper提供了临时节点,sequence,和变更通知。利用Zookeeper的这3个特性实现了按照sequence的顺序依次获取锁和成为主。

etcd没有临时节点的概念,但是通过租约的方式提供了类似的功能。etcd没有sequence的概念,但是提供了全局递增的序列号revision,通过判断每个key的revision,也可以实现类似的sequence功能。提供多键条件事务(类似etcdv2的Compare-and-Swap)。虽然提供的机制不同与Zookeeper,但是实现的锁方式和选主方式与zookeeper非常类似,也是按照key建立时间依次获得锁和成为主。

consul也没有临时节点的概念,但是有session的概念,通过session也可以实现临时节点的功能。consul没有提供sequence的功能,类似于etcd也提供了modifyindex,这种全局递增的序号。consul的接口类对外暴露了cas(check-and-set)的语意(似于etcdv2),与此同时对外直接暴露了锁的语意。提供了与etcd相同的机制,额外还提供了锁的机制。所以基于consul不需要考虑怎么实现锁,只需要考虑实现选主。官方文档中给出的选主的实现,是基于锁机制的,所以consul的选主不同与zookeeper和etecd。Zookeeper和etcd的实现可以避免群惊现象。但是consul提供类似于etcd的机制,所以也可以不基于锁的来实现选主,也可以实现出类似于etcd的选主实现。

总结,zookeeper、consul、etcd实现锁和选主时依赖自身的多个机制,但是有最核心的机制,比如zookeeper的sequence机制,etcd的revision和多键条件事务,consul的index、cas和锁,以上这些特性归根结底是3个系统的consistency的特性的一种表现。

时间: 2024-10-24 05:04:54

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

用Zookeeper实现分布式锁和选主

Zookeeper可以用来实现Distributed lock(分布式锁)和leader election(选主). 分布式锁和选主虽然用在不同的场景,但是2者的机制是相同的. Zookeeper官方文档上给出了一个recipes,介绍了如何实现分布式锁和选主,2种实现说明的步骤和风格完全不一样,但是本质是一样的. 这里先翻译一下recipes对2者的说明. 获得锁的步骤: 1.调用create(),以"_locknode_/lock-"作为路径名,并且设置sequence和ephem

用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(租约)的概念

用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实现分布式锁

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

基于Redis的分布式锁真的安全吗?(下)

自从我写完这个话题的上半部分之后,就感觉头脑中出现了许多细小的声音,久久挥之不去.它们就像是在为了一些鸡毛蒜皮的小事而相互争吵个不停.的确,有关分布式的话题就是这样,琐碎异常,而且每个人说的话听起来似乎都有道理.   今天,我们就继续探讨这个话题的后半部分.本文中,我们将从Antirez反驳Martin Kleppmann的观点开始讲起,然后会涉及到Hacker News上出现的一些讨论内容,接下来我们还会讨论到基于Zookeeper和Chubby的分布式锁是怎样的,并和Redlock进行一些对

分布式锁的三种实现方式

分布式锁大有用途,比如用在减库存操作.流水号生成,分布式计数器等.分布式锁服务在大家的项目中或许用的不多,因为大家都把排他放在数据库那一层来挡.当大量的行锁.表锁.事务充斥着数据库的时候.一般web应用很多的瓶颈都在数据库上,这里给大家介绍的是减轻数据库锁负担的方案--分布式锁服务.本文介绍分布式锁常用的三种实现方式.   一.zookeeper 1.实现原理: 基于zookeeper瞬时有序节点实现的分布式锁,其主要逻辑如下(该图来自于IBM网站).大致思想即为:每个客户端对某个功能加锁时,在

基于Consul的分布式锁实现

我们在构建分布式系统的时候,经常需要控制对共享资源的互斥访问.这个时候我们就涉及到分布式锁(也称为全局锁)的实现,基于目前的各种工具,我们已经有了大量的实现方式,比如:基于Redis的实现.基于Zookeeper的实现.本文将介绍一种基于Consul 的Key/Value存储来实现分布式锁以及信号量的方法. 分布式锁实现 基于Consul的分布式锁主要利用Key/Value存储API中的acquire和release操作来实现.acquire和release操作是类似Check-And-Set的

基于ZooKeeper的分布式锁和队列

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

ZooKeeper 笔记(6) 分布式锁

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