1 概述
我们大家都知道集群一般是由两个或两个以上的服务器组建而成，每个服务器都是一个节点。也会听到数据库集群、管理集群等概念，也知道数据库集群提供了读写功能，管理集群提供了管理、故障恢复等功能。那么对于一个集群来说，多个节点到底是怎么协同，怎么管理的呢？比如，数据库集群，如何保证写入的数据在每个节点上都一致呢？答案是选一个“领导”来负责调度和管理集群中其他节点。这个“领导”，在分布式中叫做主节点，而选“领导”的过程在分布式领域中叫作分布式选举。选举的作用就是选出一个主节点，由它来协调和管理其他节点，以保证集群有序运行和节点间数据的一致性。
2 分布式选举的算法
2.1 Bully 算法
Bully 算法是一种霸道的集群选主算法，为什么说是霸道呢？因为它的选举原则是“长者”为大，即在所有活着的节点中，选取 ID 最大的节点作为主节点。
在 Bully 算法中，节点的角色有两种：普通节点和主节点。初始化时，所有节点都是平等的，都是普通节点，并且都有成为主的权利。但是，当选主成功后，有且仅有一个节点成为主节点，其他所有节点都是普通节点。当且仅当主节点故障或与其他节点失去联系后，才会重新选主。
Bully 算法在选举过程中，需要用到以下 3 种消息：
- Election 消息，用于发起选举；
- Alive 消息，对 Election 消息的应答；
- Victory消息，竞选成功的主节点向其他节点发送的宣誓主权的消息。
Bully 算法的具体的选举过程是：
- 集群中每个节点判断自己的 ID 是否为当前活着的节点中 ID 最大的，如果是，则直接向其他节点发送 Victory消息，宣誓自己的主权；
- 如果自己不是当前活着的节点中 ID 最大的，则向比自己 ID 大的所有节点发送 Election消息，并等待其他节点的回复；
- 若在给定的时间范围内，本节点没有收到其他节点回复的 Alive 消息，则认为自己成为主节点，并向其他节点发送Victory 消息，宣誓自己成为主节点；
- 若接收到来自比自己 ID 大的节点的 Alive 消息，则等待其他节点发送 Victory消息；
- 若本节点收到比自己 ID 小的节点发送的 Election 消息，则回复一个 Alive 消息，告知其他节点，我比你大，重新选举。
Bully 应用场景
目前已经有很多开源软件采用了 Bully 算法进行选主，比如 MongoDB。MongoDB 的分布式选举中，采用节点的最后操作时间戳来表示 ID，时间戳最新的节点其 ID 最大，也就是说时间戳最新的、活着的节点是主节点。
Bully 算法小结
Bully 算法的选择很简单，就是看谁活着且谁的 ID 最大谁就是主节点，其他节点必须无条件服从。
**优点：**选举速度快、算法复杂度低、简单易实现。
**缺点：**需要每个节点有全局的节点信息，因此额外信息存储较多；其次，任意一个比当前主节点 ID 大的新节点或节点故障后恢复加入集群的时候，都可能会触发重新选举，成为新的主节点，如果该节点频繁退出、加入集群，就会导致频繁切主。
2.2 Raft 算法
Raft 算法是典型的多数派投票选举算法，核心思想是：“少数服从多数”，也就是说获得投票最多的节点成为主。
** Raft 算法选举，集群节点的角色有 3 种：**
- Leader，即主节点，同一时刻只有一个 Leader，负责协调和管理其他节点；
- Candidate，即候选者，每一个节点都可以成为Candidate，节点在该角色下才可以被选为新的 Leader
- Follower，Leader 的跟随者，不可以发起选举。
Raft 选举的流程，可以分为以下几步：
- 初始化时，所有节点均为 Follower 状态。
- 开始选主时，所有节点的状态由 Follower 转化为****Candidate，并向其他节点发送选举请求。
- 其他节点根据接收到的选举请求的先后顺序，回复是否同意成为主。这里需要注意的是，在每一轮选举中，一个节点只能投出一张票。
- 若发起选举请求的节点获得超过一半的投票，则成为主节点，其状态转化为Leader，其他节点的状态则由 Candidate 降为 Follower。Leader 节点与 Follower节点之间会定期发送心跳包，以检测主节点是否活着。
- 当 Leader 节点的任期到了，即发现其他服务器开始下一轮选主周期时，Leader节点的状态由 Leader 降级为 Follower，进入新一轮选主。
节点间的状态转移如下图所示：
注意：每一轮选举，每个节点只能投一次票
Raft 算法选主是周期进行的，包括：选主和任值两个时间段，选主阶段对应投票阶段，任值阶段对应节点成为主之后的任期。但也有例外的时候，如果主节点故障，会立马发起选举，重新选出一个主节点。
Raft算法应用场景
Kubernetes 为了保证可靠性，通常会部署 3 个节点，其中会有一个被选为主，其他节点作为备。Kubernetes 的选主采用的是开源的 etcd 组件。而 etcd 就是采用了 Raft 算法来实现选主和一致性的。
Raft算法小结
- **优点：**具有选举速度快、算法复杂度低、易于实现；稳定性较比Bully要好，因为当有新节点加入或节点故障恢复后，会触发选主，但不一定会真正切主，除非新节点或故障后恢复的节点获得投票数过半，才会导致切主。
- **缺点：**它要求系统内每个节点都可以相互通信，且需要获得过半的投票数才能选主成功，因此通信量大。
2.3 ZAB 算法
ZAB（ZooKeeper Atomic Broadcast）选举算法是为 ZooKeeper 实现分布式协调功能而设计的。相较于 Raft 算法的投票机制，ZAB 算法增加了通过节点 ID 和数据 ID 作为参考进行选主，节点 ID 和数据 ID 越大，表示数据越新，优先成为主。相比较于 Raft 算法，ZAB 算法尽可能保证数据的最新性。所以，ZAB 算法可以说是对 Raft 算法的改进。
使用 ZAB 算法选举时，集群中每个节点拥有 3 种角色
- Leader：主节点；
- Follower：跟随者节点；
-
Observer：观察者，无投票权。
选举过程中，集群中的节点拥有 4 个状态： - Looking 状态，即选举状态。当节点处于该状态时，它会认为当前集群中没有 Leader，因此自己进入选举状
- Leading状态，即领导者状态，表示已经选出主，且当前节点为 Leader。
- Following状态，即跟随者状态，集群中已经选出主后，其他非主节点状态更新为 Following，表示对 Leader 的追随
-
Observing状态，即观察者状态，表示当前节点为 Observer，持观望态度，没有投票权和选举权。
投票过程中，每个节点都有一个唯一的三元组 (server_id, server_zxID, epoch)，其中 ： - server_id 表示本唯一的节点ID；
- server_zxID 表示本节点存放的数据 ID，数据 ID 越大表示数据越新，选举权重越大；
- epoch 表示当前选取轮数，一般用逻辑时钟表示。
ZAB 选举算法的核心是“：少数服从多数，ID 大的节点优先成为主”，因此选举过程中通过 (vote_id, vote_zxID) 来表明投票给哪个节点，其中 vote_id 表示被投票节点的 ID，vote_zxID 表示被投票节点的服务器 zxID。
ZAB 算法选主的原则是：server_zxID 最大者成为 Leader；若 server_zxID 相同，则 server_id 最大者成为 Leader。
接下来以 3 个 Server节点 的集群为例，来介绍 ZAB 选主的过程： - 第一步：当系统刚启动时，3 个服务器当前投票均为第一轮投票，即 epoch=1，且 zxID 均为 0。此时每个服务器都推选自己，并将选票信息 广播出去。
- 第二步：根据判断规则，由于 3 个 Server 的 epoch、zxID 都相同，因此比较 server_id，较大者即为推选对象，因此 Server 1 和 Server 2 将 vote_id 改为 3，更新自己的投票箱并重新广播自己的投票
- 第三步：此时系统内所有服务器都推选了 Server 3，因此 Server 3 当选 Leader，处于 Leading 状态，向其他服务器发送心跳包并维护连接；Server1 和 Server2 处于 Following 状态。
ZAB 算法小结
- 优点：1、ZAB算法性能高，对系统无特殊要求；2、算法选举稳定性比较好，当有新节点加入或节点故障恢复后，会触发选主，但不一定会真正切主，除非新节点或故障后恢复的节点数据 ID 和节点 ID 最大，且获得投票数过半，才会导致切主
- 缺点：1、采用广播方式发送信息，若节点中有 n 个节点，每个节点同时广播，则集群中信息量为 n*(n-1) 个消息，容易出现广播风暴；2、且除了投票，还增加了对比节点 ID 和数据 ID，这就意味着还需要知道所有节点的 ID 和数据 ID，所以选举时间相对较长。