关于raft:不使用Raft算法就能简单做集群leader选举

9次阅读

共计 1371 个字符，预计需要花费 4 分钟才能阅读完成。

在互联网的高速倒退下，如果服务器不应用个集群模式，本人都不好意思进来面试。目前所知的大部分集群模式都是基于中心化思维来部署，而中心化的思维是建设在服务器选举 Leader 规定之上，驰名的一致性算法 Raft 能够实现集群的选举工作，不过 Raft 算法也不是个别程序员能够把握的。

集群的选举次要是为了能让集群失常工作，在不应用 Raft 等简单算法的前提下，是否能够搞定集群的选举工作呢？当然能够，不过要借助其余技术，明天就来说一说，如何利用 zookeeper 来搞定集群选举 Leader 的工作。

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的性能包含：配置保护、域名服务、分布式同步、组服务等。

Zookeeper 的节点相似于 UNIX 文件系统，是一个简略目录树结构的数据模型，在这棵树中，每个节点都能够作为一个 ZNode，每一个 ZNode 都能够通过惟一门路来标识

在 Zookeeper 中，节点（ZNode）分为几个类型，其中有一个类型为临时性节点，它有个特点：它的生命周期和创立这个节点的客户端 Session 绑定，一旦这个客户端掉线或者 down 机，这个节点就会主动删除。

Zookeeper 提供了节点变动告诉机制，即 Watch 机制。每个客户端能够抉择任意的节点进行监听，如果被监听的节点或者子节点发生变化，便会告诉所有监听的客户端，基于这个原理就能实现集群服务器的主动发现机制。

一个分布式的集群服务，最重要的就是不间断的提供服务，或者说是容错性。当一个节点因为故障起因退出集群或者一个新节点退出集群，不会影响集群的服务能力。当 Leader 节点呈现故障，能实现主动选举性能，而不必人工干预，那利用 Zookeeper 怎么做到呢？

首先必须要有几个约定：

具体的过程如下：

当集群的第一个服务器启动，注册本人的信息到 Zookeeper 固定节点下，并监听此节点的变动。发现只有本人一个服务器，则默认入选 Leader。
当其余服务器启动并注册信息到雷同节点下，并监听此节点信息变动。发现曾经有 Leader，默认作为 follower 进行工作。
当 Leader 因为故障掉线，信息会主动从 Zookeeper 删除，其余节点会收到告诉，而后把 Leader 节点踢除，进入下一个 Leader 选举流程。
存活的服务器中，依据约定，名字最小的服务器入选 Leader，并向其余服务器发送告诉，这个时候集群能够持续失常工作。
如果是非 Leader 节点掉线，流程和以上相似，然而少了选举的过程。

就算是在选举过程中继续有客户端掉线也没有关系，因为 Zookeeper 能保障最终的数据一致性，在加上咱们约定的名字最小的为 Leader 的束缚，最终集群的状态将达到稳固。

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