Raft协议

• 首先给大家推荐一个极其好用的Raft的图解网址，相当好用，自己跑一遍跟着这个去理解
• Raft的图解网址

1. 什么是Raft

• Raft是一个共识算法，所谓的共识指的就是多个节点对某个事情达成一致的看法，即使是在部分节点故障，网络延迟，网络分割的情况下。
• Raft协议是Paxos的简化
• Raft会先选举出leader，leader完全负责日志副本的管理。leader负责接收所有客户端的更新的请求（写请求），然后复制到follower节点，并且在安全的时候执行这些请求。如果leader故障了，follower会重新选举出新的leader。

2. Raft相关概念介绍

2.1 term

• 在选举的时候，我们哪个节点作为leader是通过选举投票选举出来的，每个leader工作一段时间，然后选出新的leader继续负责
• 这个与民主主义的选举是非常的相像的，每一届的任职期间称之为一届的任期，在raft协议中，也是这样的，这个任期就是我们的term
• term（任期）是以选举开始，然后就是一段或长或短的稳定工作期，任期是递增的，这就充当了逻辑时钟的作用。注意，如果在任期期间，没有选举出leader，任期就已经结束了，此时就会发生新的选举，如下图所示
  

2.2 Raft协议中的节点状态

• 在Raft协议中，leader的选举的时候节点是有三种状态的。
  （1）leader
  （2）follower
  （3）candidate（候选状态）

（1）节点启动的时候都是follower状态，在一段时间内如果没有收到来自leader的心跳，从follower就切换到candidate状态，发起选举。如果收到了半数的投票，则切换成leader；如果发现其他节点已经更新为leader，则自己主动切换到follower节点。
（2）简而言之，就是系统中最多只有一个leader，如果再一段时间内没有发现leader，则大家就会通过选举投票选出leader。leader会不停的给follower发送心跳消息，表名自己的存活状态。如果leader故障了，那么follower就会切换到candidate状态，重新选举出一个leader出来。
（3）想要开始选举，就需要让节点先变成candidate状态

3. 图解Raft协议的选举

3.1 节点状态

• 我们的节点分为3种状态
  （1）follower
  （2）leader
  （3）candidate

follower

leader

candidate（候选状态）

3.2 leader的选举图解

【1. 我们的所有的节点都是以follower的状态开始的】

【2. 如果follower没有收到leader的心跳，那么他们可以成为candidate状态，即候选人状态】

【3. candidate状态的节点从其他节点请求投票】

【4. 当前candidate状态的节点从其他节点收到响应，节点将进行投票表决，如果候选人从多数节点中获取选票，他就会成为领导者】

• 上面的过程就是leader的选举，系统的所有的更改现在都会通过领导者（即leader节点）去实现。

3.3 日志复制同步图解

• 注意：日志的复制我们是以心跳进行发送的。

【1. 数据同步，系统的更改等现在都是通过新的leader来进行的，并且每次的更改都会在日志中添加对应的信息，因为当前的日志信息没有提交，所以不会更新节点的值（所以这里的SET 5是红色的，表示没有提交）】

【2. 想要提交日志，节点首先要将其复制到follower节点上】


【3. 然后领导者（leader）进行等待，直到大多数的节点都写成功了，就是半数以上的follower都写成功这个数据了】

【4. 此时，将leader节点进行提交，节点状态变为5，表示已经修改成功】

【5. 然后，leader节点通知follower节点该节点日志已经提交】

【6. 此时follower节点的状态已经和leader节点的状态一直，达成了共识】

上面的过程就是日志复制的过程，利用发送给leader，leader与follower的同步进行同步

3.4 leader的选举机制详细介绍

• 在raft中有两个超时可以设置
  （1）选举超时
  （2）心跳超时

1. 选举超时指的是追随者称为候选人之前所等待的时间，就是follower变为candidate之前的等待时间。
2. 选举超时是随机的，一般随机分配在150ms-300ms之间
3. 选举先超时的节点就会由follower变为candidate（候选者）

3.4.1 图解leader的选举机制

【1. 开始选举，无法收到leader的心跳，开始等待选举超时，由最先变为candidate的机子开始选举】

【2. 选举超时之后，follower就变为候选人（candidate）并且开始新的选举任期（term）】

• 上图的term变为1，是因为选举任期是递增的，初始为0
• vote count是1，表示的是当前的节点为自己投票，投了一票所以+1，变为1

【3. 先会投票给自己，然后候选者的节点会向其他的节点发送请求投票的消息】

【4. 如果接收到要投票的follower节点在当前的任期内，还没有进行投票，就会将投票直接投给候选人节点，并且重置选举超时时间】

【5. 一旦候选人获得多数投票，即过半投票，就可以成为领导者】

【6. leader会向其他的follower发送添加条目的消息】

注意：这些消息以 心跳超时 指定的时间间隔发送的（应该就是每次心跳的时候发送添加条目的消息）
收到消息之后，就会重置follower节点的选举超时，重新计算

【7. follower会响应每个追加条目的消息】

注意：
这个选举任期会持续到follower停止接受心跳并且成为候选人为止

1. 此时如果停掉当前的leader，我们可以发现NodeB的选举时间是先到的，所以NodeB会变为candidate然后发起投票，成为新的leader
2. 因为是3个节点，所以只要投票大于1即可，所以自己的一票加上NodeC的一票，使其会成为新的leader

【8. 节点B现在是任期2（term：2）的leader】

注意

• 一个集群中只能有一个leader，如果两个节点同时成为候选节点，就可能发生拆分表觉
• 什么时候会发生这种情况呢？
  这种情况一般发生在 两个节点的选举超时时间一模一样，此时就会有两个节点同时follower状态变为candidate状态，此时就会收到相同的票数。
  
  此时明显是不合理的，所以此时我们就会进行重试，重新设置其选举超时时间，让其再次重新选举。

3.5 网络分区的问题图解

【1. 假设我们有五个节点，因为分区的原因，导致原来的NodeC选举成为一个新的leader，本身只有NodeB是Leader】

【2. 我们现在添加另一个客户端，并且尝试更新两个领导者】

【3. 其中一个客户端尝试将节点B的值设置为3】

• 注意：
  这里我们是设置不成功的，因为节点B这边只有两个节点，对于半数机制，最起码应该是5/2=2.当我们的机器最起码有>2的机子，也就是3台同步成功的时候才可以写成功，所以这里的日志条目一直是未提交的状态

【4. 发现不满足过半机制，所以无法同步成功，写失败】

【5. 此时，另一个客户端尝试将节点C的值设置为8】

这里就是可以成功设置的，因为我们的节点C那边有三台机子，完全可以满足半数投票机制，自己的投票 + 其他两个follower的机子的投票 = 3 > 5/2，所以可以同步成功，也就说这个过程是写成功的。

3.5.1 补充知识点

1. 节点C是新选举出来的Leader，所以term变为了2，但是节点B是原来的leader，所以term还是1
2. 此时如果恢复了分区，我们发现节点B和节点C都是主节点，但是节点B的term是小于节点C的term的，所以节点B看到了较高的选举任期并且退出，老老实实的做一个follower，并且term也进行了变更，节点A和节点B都将回滚未提交的条目，并且匹配新的leader日志。
   

注意：

1. term小的服从term大的，还要回滚未提交的条目，并且匹配新的leader日志
2. term是选举任期，在最前的时候介绍过了。
3. ZK使用的是ZAB协议，Nacos的CP原则使用的是类似的Raft的协议。Raft和ZAB都是分布式一致性协议Paxos的简化，两者是类似的，主要包括两个部分：
   （1）leader的选举（半数以上的节点投票）
   （2）集群写入数据同步（两阶段提交），即uncommited和commited

• 因为Nacos的CP使用的是类似Raft的协议，我们没有使用两阶段提交，而是使用了CountDownLanuch，但是保证了半数机制