当前位置：首页 > news >正文

角色、人气及角色转变

news 2026/6/29 7:40:34

Leader选举

我要选举
当follower没有接收到leader的心跳，则认为leader挂了。此时先使其本地term加1.然后完成下面步骤：
- 此时若接收到其他candidate 的投票请求，就投票给这个candidate
- 由follower转变为candidate
- 若之前未投票，就投自己一票
- 向其他节点发出投票请求，然后等待响应。
我要投票
follower 在接收到投票请求后，根据以下情况判断是否投票：
- 发来投票请求的candidate的term不能小于我的term
- 在我当前term内，我的选票还没有投出去
- 若接收到多个candidate的请求，采取first-come-first-served方式投票
等待响应
当一个candidate 发出投票后，会等待其他节点的响应结果，这个结果有三种情况：
- 收到过半选票，成为新的leader,然后通知其他节点。
- 接收到别的candidate 发来的新leader通知，比较新leader的term 不比自己的term小，将自己变未follower
- 经过一段时间后，没有收到过半选票，也没有收到新leader通知，则重新开始选举。
选举时机
很多时候，当Leader真的挂了，Follower几乎同时感知到，然后几乎同时变为candidate发起选举。此时会出现较多candidate 票数相同情况，就无法选举出Leader。
为了防止这种情况，Raft算法采用randomized election timeouts 策略解决这个问题。其会为这些Follower随机分配一个选举发起时间 election timeout,这个timeout 在150-300ms范围内。只有到达election timeout 时间的Follower 才能转变为candidate，否则等待。那么 election timeout 较小的Follower 则会转变为candidate 然后发起选举，一般情况下，先获取到过半选票的节点成为新的leader。

数据同步

在Leader 选举出来的情况下，通过日志复制实现集群中各节点数据的同步。

状态机
Raft算法一致性是基于日志复制状态机来实现的。状态机最大的特征是：不同Server中的状态机若当前状态相同，然后接收了相同的输入，那么输出必然相同。
处理流程

当leader接收到client的写请求后，会经历以下流程：

leader会将数据与term封装为一个box，并随着下一次心跳发送给所有followers，征求大家对该box的意见。同时将本地数据封装为日志。
follower 接收到来自leader的box后先比较该box的term比自己的小就接受该box，并向leader回复同意。同时将该box中的数据封装为日志。
当leader接收到过半同意响应后，将日志commit到本地的状态机，状态机输出一个结果，同时日志状态变为了committed
同时leader会通知所有follower 将日志commit到本地的状态机，日志状态变为了committed
在commit 通知发出同时，leader 也会向client发出成功处理的响应。
AP支持
为保证可用性。各个节点中的日志可以不完全相同，但leader会不断给follower发送box，以使各个节点的log达到最终相同。即Raft算法不是强一致性，而是最终一致性。
脑裂
在多机房部署中，由于网络问题，很容易形成多个分区，而多分区很容易产生脑裂，从而导致数据不一致。
以三机房部署为例，可以分为五种情况：
1. 不确定

B感知不到Leader，所以会发起选举，但是C能感知到Leader，但是由于其接收到了更大term的投票请求，所以C也放弃了A中的Leader，参与了新的选举。

若leader出现在B机房，A是感知不到新Leader的诞生，其不会自动下课，就会形成脑裂。由于A中的Leader处理的写操作无法获取到过半响应，所以无法完成写操作。

但B中的Leader的写操作处理可以获取到过半响应，所以能完成写操作，故A与B、C中出现脑裂，且形成了数据不一致。

若新Leader出现在C机房，A中的Leader会自动下课，所以不会形成脑裂。