Raft概述

Raft

1. 概述

Raft是一种一致性(共识)算法，相比Paxos，Raft更容易理解和实现，它将分布式一致性问题分解成多个子问题，Leader选举（Leader election）、日志复制（Log replication）、安全性（Safety）、日志压缩（Log compaction）等。

1.1 角色

Raft中的角色分为：

• Leader：接受客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后告诉Follower提交日志。
• Follower：接受并持久化Leader同步的日志，在Leader告之日志可以提交之后，提交日志。
• Candidate：Leader选举过程中的临时角色，即候选人。

Raft要求系统在任意时刻最多只有一个Leader，正常工作期间只有Leader和Followers。Raft算法将时间分为一个个的任期（term），每一个term的开始都是Leader选举。在成功选举Leader之后，Leader会在整个term内管理整个集群。如果Leader选举失败，该term就会因为没有Leader而结束。

1.2 任期

Raft算法将时间分为任意不同长度的任期（Term），用连续递增的数字来表示。每个任期都开始于选举（election），一个或者多个Candidate（候选人）会试图成为领导者。如果一个候选人在该轮选举获得了大多数投票（N/2 + 1），则将成为该任期的领导者。在某些情况下，选票可能会被瓜分，则该轮可能没选出领导者，那么将会开始另一个任期，并进行下一次选举。Raft算法保证在任意一个任期内，最多只有一个领导者。

1.3 RPC

Raft算法中每个服务器使用RPC（远程过程调用）进行通信，分为以下三种。

• RequestVote RPC：候选人在选举期间发起。
• AppendEntries RPC：领导人发起的一种心跳机制，复制日志也在该命令中完成。
• InstallSnapshot RPC: 领导者使用该RPC来发送快照给太落后的追随者。

2. 选举

2.1 概述

当服务启动时，每个角色初始化为follower，如果follower没有接收到来自leader的heartbeat（心跳）,则将成为候选者。候选人向其他节点发送投票请求，其他节点则进行答复。当候选人获得大多数投票时，将成为领导者。这个过程就叫做Leader Election。

请求投票

得到大多数投票，成为leader。

每一个follower都有一个时钟，是一个随机的值，表示的是follower等待成为candidate的时间，谁的时钟先跑完，则发起leader选举。

Follower将其当前term加一然后转换为Candidate。它首先给自己投票并且给集群中的其他服务器发送 RequestVote RPC。结果有以下三种情况：

• 赢得了多数的选票，成功选举为Leader；
• 收到了Leader的消息，表示有其它服务器已经抢先当选了Leader；
• 没有服务器赢得多数的选票，Leader选举失败，等待选举时间超时后发起下一次选举。

2.2 超时时间

Raft算法中有两个超时时间，分别为选举超时（election timeout）和心跳超时（heartbeat timeout）。

选举超时为follower一直等待直到变为candidate的总时间，此时间是随机的，150ms~300ms，当时间走完，则follower变为candidate，进行新一轮term的选举。

它首先给自己投票并且给集群中的其他服务器发送 RequestVote RPC。如果接收到请求的node在本任期内还没投票，则该node将给候选人投上一票，同时该node重置自己的election timeout。当候选人得到大多数投票时，他将成为领导者。leader将开始发送Append Entry给follower，这些消息按心跳超时指定的时间间隔发送。

follower会对这些信息进行response，即follower每接收到一条Append Entry，会进行一次response，如此循环。当任意一个follower停止接收到心跳并成为候选人时，该任期结束。

2.3 Splite Vote

两个node在同一个任期内发起选举，且获得同数量的投票，此时无法选举出新的leader，那么node将重新等待新一轮的选举到来，由于选举超时是随机的，所以两个node再次同时发起选举的几率就比较低，只有一个node成为新的leader。

3. 日志复制

客户端与leader进行通信，客户端得请求到达leader后，leader生成日志记录（log entry），但此时log还未提交，故值未更改。

leader则尝试发起AppendEntries rpc请求给follower，让他们复制这条日志，则leader将一直等待，直到大部分follower复制了这条日志。这时候，这条日志被提交，值被更改。然后leader再通知follower，这条日志已经被提交，现在整个集群得状态是一致的。

3.1如何处理网络分区

如果发生了网络分区，此时系统会有两个leader，分别为任期1的Node B和任期3的Node E。此时如果有两个客户端，分别连上两个leader。node E能提交，因为能达到大多数请求的回复。由于B无法达到大多数请求的回复，故客户端的SET 3命令是未提交的。

然后网络恢复，则node A和B将回滚未提交的日志，与新的leader进行匹配。最终系统将一致。