Zookeeper和Consul在实现leader election时的区别-阿里云开发者社区

开发者社区> 云计算> 正文
登录阅读全文

Zookeeper和Consul在实现leader election时的区别

简介:

Zookeeper和Consul都可以在分布式系统中用来做选主(leader election),但是两个的实现是有区别的。

首先,我们来看看Zookeeper的实现方式。用Zookeeper实现leader election可以参看另外的一篇文章,这里就不再重复了。

接下来,我们看看Consul实现leader election的过程是这样的过程(这个过程主要翻译自Consul的文档):

  • 1.所有客户端都竞争操作一个key,比如这个key是service//leader。
  • 2.所有客户端创建一个session,创建成功后每个客户端都会获得一个sessionid。
  • 3.所有想成为leader的客户端都试图去更新这个key,并且所有客户端都acquire=这个请求参数。acquire是consul在kv存储的api上扩展的功能。acquire的意思是获取更新这个key的锁,session是我们步骤2中每个客户端各自创建的session。如果请求返回true,则这个客户端获得了锁,并且成功的更新了这个key,称为了leader。如果返回false,则其他客户端获得了锁。
  • 4.如果没有获得锁,则watch这个key,如果这个发生变化,并且这个key中session信息为空,则所有当前没有客户端获得锁,重复步骤3获取锁。

比较Zookeeper和Consul实现leader election的方式,我们可以看出,Zookeeper提供sequence这种特性,而Consul本身就提供了锁的特性。我们可以基于sequence的特性,分别构建分布式锁和选主(2者本质是相同的)。Consul利用锁机制实现选主。

Zookeeper的选主是利用了sequence的特性保证同时连接上来的多个客户端都分配一个不重复序号。大家按序号的大小,从小到大依次称为leader。因为每个客户端watch的是比自己序号小的那个节点,当leader失效时,只有一个备选会收到通知。也就是不会出现群惊现象。

Consul保证同时连接上来的多个客户端只有一个可以获得锁,其他客户端不会获得锁。但当前leader失效时,所有其他的客户端都会收到通知,再一起来竞争锁。从这一点来说没有Zookeeper实现的优雅。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云计算
使用钉钉扫一扫加入圈子
+ 订阅

时时分享云计算技术内容,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。

其他文章