不使用Raft算法,就能简单做集群leader选举

在互联网的高速发展下,如果服务器不使用个集群模式,自己都不好意思出去面试。目前所知的大部分集群模式都是基于中心化思想来部署,而中心化的思想是建立在服务器选举Leader规则之上,著名的一致性算法Raft可以实现集群的选举工作,不过Raft算法也不是一般程序员可以掌握的。

集群的选举主要是为了能让集群正常工作,在不使用Raft等复杂算法的前提下,能否可以搞定集群的选举工作呢?当然可以,不过要借助其他技术,今天就来说一说,如何利用zookeeper来搞定集群选举Leader的工作。

Zookeeperg P ^

ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的ChubbX 7 % Jy一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件O 0 r T , F h 9 *,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

Zookeeper的节点类似于UNIX文件系统,是一个简_ 1 ! N s g + l单目录树结构的数据模i X w | J { T q型,在这棵树中,每个节点都可以作为一G ! [ C H个ZNode,每一个ZNode都可以通过唯一路径来标识
不使用Raft算法,就能简单做集群leader选举

临时性节点

在Zookeeper中,节点(ZNode)分为几个类型,其中有一个类型o # K 6 _ ! = j n为临时性节点,它有个特点:它的生命周期和创建这个节点的客户端Session绑定,一旦这个客户端掉线或者downT Q Z ; D机,这个节点就会自动删除。` Z ~ % 1 n ` Z O

Watch

Zookeeper提供了节点变化通知机制,即) ] KWatch机制。每个d x k / /客户端可以选择任意的节点进行监听,如果被监听的节点或者子节点发生变化,便会通知所有监听的客户端,基于这个原理就能实现集群服务器的自动发现机制。

集群的选举

一个分布式的集群服务,最重要的, 3 R (就是不间断的提供服务,或者说是容错性。当一个节点由于故障原因退出集群或者一个新节点加入集群,不会影响集群的服务能力。当Leader节点出现故障,能实现Q P w 2 . &自动选举功能,而不用人工干预,i z i U 6那利用Zookeeper怎么做到呢?

首先必须要有几个约定. N C

  • 所有的集群服务器监听相同的Zookeeper节点,这个节点充当集群信息的存储
  • 集群中的服务器可以利b Z ) u i用ip或者机器名作为节点名称,不允许有重复的节点名称
  • 集群默认采用名称排序最小的服务器6 f ] [ ` # k作为Leader

具体的过程如下:

  • 当集群的第一A 6 7 X Q 7 L -个服务器启动,注册自己的信f . r T P a V J !息到ZookeepN ` k | 4er固定节点下,并监听此节点的变化。发现只有自己一个服务器,则默认当选Leader。
  • 当其他服务器启动并f D f b x注册信息到相同节点下,并监听此节点信息变V a j /化。发现已经有Leader,默认作为follower进行工作。
  • 当Leader由于故障掉线,信息会自动从Zookeeper删除,其他节点会收到通知,然后把Leader节点踢除,进入下K ) i k 0 & B一个Leader选举流程。
  • 存活的服务器中* E - l,根据约定,名字最小的服务器当选Leader,并向其他服务器发送通知,这个时候集群可以继续正常工作。
  • 如果是非Leadp E t } Ger节点掉线0 w % B M K I 7,流程和以上V e : A U类似,但是少了选举的过程。

就算是在选举过程中持续有客户端掉线也没有关系,因为Zookeeper能保证最终的数据一致性,在加上我们约定的名字最小的为Leader的约束,最终集群的状 % L v } T态将达到稳定。

这里提出一个新问题,利用Zookeeper来进行集群的选举,会不会出现脑裂问题呢?

更多精彩文章

  • 分布式大并发系列
  • 架构设计系列
  • 趣学算法和数据结构系列
  • 设计模@ F R式系列

不使用Raft算法,就能简单做集群leader选举