浅谈分布式一致性：Raft 与 SOFAJRaft

一 分布式共识算法 (Consensus Algorithm)

1 如何理解分布式共识?

多个参与者针对某一件事达成完全一致：一件事，一个结论。

已达成一致的结论，不可推翻。

2 有哪些分布式共识算法?

• Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）。
• Zab：被应用在 zookeeper 中，业界使用广泛，但没用抽象成通用 library。
• Raft：以容易理解著称，业界也涌现出很多 raft 实现，比如 etcd、braft、tikv 等。

二 Raft 介绍

1 特点：Strong Leader

• 系统中必须存在且同一时刻只能有一个 leader，只有 leader 可以接受 clients 发过来的请求。
• Leader 负责主动与所有 followers 通信，负责将“提案”发送给所有followers，同时收集多数派的 followers 应答。
• Leader 还需向所有 followers 主动发送心跳维持领导地位（保持存在感）。

另外，身为 leader 必须保持一直 heartbeat 的状态。

2 复制状态机

对于一个无限增长的序列a[1, 2, 3…]，如果对于任意整数i， a[i]的值满足分布式一致性， 这个系统就满足一致性状态机的要求。

基本上所有的真实系统都会有源源不断的操作，这时候单独对某个特定的值达成一致显然是不够的。为了让真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(WAL)。然后让系统中所有副本对 WAL 保持一致，这样每个副本按照顺序执行 WAL 里的操作，就能保证最终的状态是一致的。

• Client 向 leader 发送写请求。
• Leader 把“操作”转化为 WAL 写本地 log 的同时也将 log 复制到所有 followers。
• Leader 收到多数派应答，将 log 对应的“操作”应用到状态机。
• 回复 client 处理结果。

3 Raft 中的基本概念

Raft-node 的 3 种角色/状态

• Follower：完全被动，不能发送任何请求, 只接受并响应来自 leader 和 candidate 的 message, node启动后的初始状态必须是 follower。
• Leader：处理所有来自客户端的请求，以及复制 log 到所有 followers。
• Candidate：用来竞选一个新 leader (candidate 由 follower 触发超时而来)。

Message 的 3 种类型

• RequestVote RPC：Candidate 发出。
• AppendEntries (Heartbeat) RPC：Leader 发出。
• InstallSnapshot RPC：Leader 发出。

任期逻辑时钟

• 时间被划分为一个个任期(term)，term id 按时间轴单调递增。
• 每一个任期的开始都是 leader 选举，选举成功之后，leader在任期内管理整个集群, 也就是“选举 + 常规操作”。
• 每个任期最多一个 leader，可以没有 leader (spilt-vote 导致)。

4 Raft 功能分解

Leader 选举

超时驱动：Heartbeat / Election timeout

随机的超时时间：降低选举碰撞导致选票被瓜分的概率

选举流程：Follower --> Candidate (选举超时触发)

• 赢得选举：Candidate --> Leader
• 另一个节点赢得选举：Candidate --> Follower
• 一段时间内没有任何节点器赢得选举：Candidate --> Candidate

选举动作：

• Current term++
• 发送 RequestVote RPC

New Leader 选取原则 (最大提交原则)

• Candidates include log info in RequestVote RPCs(index & term of last log entry)
• During elections, choose candidate with log most likely to contain all committed entries
• Voting server V denies vote if its log is “more complete”：(lastTermV > lastTermC) ||((lastTermV == lastTermC) && (lastIndexV > lastIndexC))
• Leader will have “most