Raft算法处理细节

Raft算法

Raft算法 是通过日志复制管理来达到集群节点一致性算法，这个日志复制管理发生在节点中的Leader和Followers之间。Leader节点负责管理日志复制过程，以实现各个节点间数据的一致性。

角色、人气及角色转变

Raft中，节点有三种角色：

• Leader：唯一复制客户端请求的节点；同时负责日志复制工作。
• Candidate：Leader选举的候选人，其可能会成为Leader。是选举过程中的角色
• Follower：可处理客户端读请求；当发现Leader挂了。就会转变为Candidate发起Leader选举。

Leader选举

1. 我要选举

   当follower没有接收到leader的心跳，则认为leader挂了。此时先使其本地term加1.然后完成下面步骤：

   • 此时若接收到其他candidate 的投票请求，就投票给这个candidate
   • 由follower转变为candidate
   • 若之前未投票，就投自己一票
   • 向其他节点发出投票请求，然后等待响应。

2. 我要投票

   follower 在接收到投票请求后，根据以下情况判断是否投票：

   • 发来投票请求的candidate的term不能小于我的term
   • 在我当前term内，我的选票还没有投出去
   • 若接收到多个candidate的请求，采取first-come-first-served方式投票

3. 等待响应

   当一个candidate 发出投票后，会等待其他节点的响应结果，这个结果有三种情况：

   • 收到过半选票，成为新的leader,然后通知其他节点。
   • 接收到别的candidate 发来的新leader通知，比较新leader的term 不比自己的term小，将自己变未follower
   • 经过一段时间后，没有收到过半选票，也没有收到新leader通知，则重新开始选举。

4. 选举时机

   很多时候，当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会自动下课，所以不会形成脑裂。

2. 形成脑裂

这种情况一定会形成脑裂

3. 无脑裂

A、C正常服务，B无法选举出新的Leader。没有形成脑裂。

4. 无脑裂

ABC均对外服务，无脑裂。

5. 无脑裂

A无法处理写请求，但可以对外服务。

BC失去了Leader，都会发起选举，但是都无法获取过半支持，都无法选出新Leader。

Leader宕机处理

请求到达前Leader挂了

client发送写请求到Leader之前Leader挂了，因为请求没到达集群，所以对集群数据的一致性没影响。

Leader挂了之后会选举产生新的Leader。

由于Stale Leader 未向client发送响应，所以client会重新发送写请求。

未开始同步数据前Leader挂了

client发送写请求给Leader，请求到达Leader后，Leader还没开始向Followers发送数据就挂了，这时选举产生新Leader。Stale Leader重启作为Follower重新加入集群，并同步新Leader 中的数据以保证数据一致性。

由于stale Leader 未发送响应，所以client会重新发送写请求。

同步完部分后Leader挂了

client 发送写请求给Leader，Leader接收后向所有Follower发送数据。在部分follower 接收到数据后Leader 挂了，然后发起选举。

• 若新Leader产生于已完成数据接收的Follower，会继续将前面接收到的写请求转换为日志，并写入到本地状态机，并向所有Follower 发出询问。在获得过半同意后向所有Followers 发送commit 指令，同时向client发出响应。
• 若新Leader 产生于尚未完成数据接收的Follower，那么原来已完成接收的Follower则会放弃接收到的数据，由于client没接收到响应，会重新发送该请求。

commit通知发出后Leader挂了

client 发送写请求给Leader，Leader也成功向所有Followers发出commit指令，并向client发出响应，然后Leader挂了。

由于已经成功响应了，说明这个操作请求被成功处理。

在网络上有一个关于Raft算法的动画，其非常清晰全面地演示了Raft算法的工作原理。 该动画的地址为：http://thesecretlivesofdata.com/raft/