标签：cli 独立 时机 代码 follow tables and leader ble
Paxos 算法的描述偏学术化，缺失了很多细节，没有办法直接应用于工程领域。实际工程应用中的分布式算法大多是 Paxos 的变种，验证这些算法的正确性也成为了一个难题。
举个例子：上一篇文章的 最后 介绍了一个应用 Paxos 算法的工程模型，这个模型存在明显的写性能瓶颈：
为了提高这个模型的性能，仍需要在很多细节上做进一步调整，最终实现出来的算法已经和原始的版本的 Paxos 相去甚远。
为了解决以上问题，另一个高性能且易于理解的一致性算法横空出世：Raft
Raft 算法基于 复制状态机Replicated State Machine模型，本质上就是一个管理 日志复制 的算法。
Raft 集群采用 Single Leader 架构，集群中有唯一的 Leader 进程负责管理日志复制，其职责有：
复制状态机的本质就是：Paxos + WAL
State Machine，并且使用一个日志存储其所要执行指令。
如果两个状态机执行按照相同的顺序，执行相同的指令，则这两个进程最终能够收敛到同个状态。如果能保证所有进程的日志一致，则每个进程的状态必定也是一致的。
为了减少不必要的网络通信，日志追加顺序由集群唯一的 Leader 决定，无须与其他节点协商。通信开销从最低 2 次降为固定的 1 次，从而大幅提高了算法的性能。
为了保证集群的可用性，当前 Leader 下线后，集群需要从存活的节点中挑选一个新的 Leader，这个过程被称为选举 election。
每次选举都会产生一个新的任期号 term（单调递增），如果选举中产生了一个新的 Leader，那么这个任期号会伴随这个 Leader 直到其下线。每个 参与者 进程都会维护一个 current_term 用于表示已知的最新任期，进程之间通过彼此交换该值来感知 Leader 变化。
/**
* 基础信息
*/
public abstract class RaftMember implements RaftParticipant {
// 响应 RPC 前需要持久化以下两个属性
protected final long currentTerm; // 已知的最新的 term（初始为 0）
protected final ID lastCandidate; // 最近一次赞成投票的 candidate
protected RaftMember(long term, ID candidate) {
this.currentTerm = term;
this.lastCandidate = candidate;
stableStorage().persist(currentTerm, lastCandidate);
}
/**
* @see RaftParticipant#currentTerm()
*/
@Override
public long currentTerm() {
return currentTerm;
}
/**
* @see RaftParticipant#votedFor()
*/
@Override
public ID votedFor() {
return lastCandidate;
}
}
日志是 Raft 的核心概念。Raft 保证日志是连续且一致的，并且最终能够被所有进程按照日志索引的顺序提交。
每条日志记录包含：
term：生成该条记录的 Leader 对应的任期index：其在日志中的顺序command：可执行的状态机指令一旦某条日志中的命令被状态机执行了，那么我们称这条记录为已提交committed，Raft 保证已提交的记录不会丢失。
Raft集群中每个进程只能担任其中一个角色：
Raft 进程间使用 RPC 的方式进行通信，实现最基础的共识算法只需 两种RPC：
/**
* RPC 接口
* */
public interface RaftService {
/**
* 复制日志+发送心跳（由 leader 调用）
* @param term leader 任期
* @param leaderId leader 在集群中的唯一标识
* @param prevLogIndex 紧接在新的之前的日志条目索引
* @param prevLogTerm prevLogIndex 对应的任期
* @param entries 日志条目（发送心跳时为空）
* @param leaderCommit leader 已经提交的日志条目索引
* @return 当 follower 中的日志包含 prevLogIndex 与 prevLogTerm 匹配的日志条目返回 true
* */
Async<RaftResponse> appendEntries(
long term, ID leaderId,
long prevLogIndex, long prevLogTerm,
Entry[] entries, long leaderCommit) throws Exception;
/**
* 选主（由 candidate 调用）
* @param term candidate 任期
* @param candidateId candidate 在集群中的唯一标识
* @param lastLogIndex candidate 最后一条日志条目的索引
* @param lastLogTerm candidate 最后一条日志条目的任期
* @return 当收到赞成票时返回 true
* */
Async<RaftResponse> requestVote(
long term, ID candidateId,
long lastLogIndex, long lastLogTerm) throws Exception;
}
基于 Single Leader 模型，Raft 将一致性问题分解为 3 个独立的子问题：
Election：Leader 进程失效后能够自动选举出一个新的 LeaderReplication：Leader 保证其他节点的日志与其保持一致Safety：Leader 保证状态机执行指令的顺序与内容完全一致为了方便理解，下面结合 动画 进行介绍。
使用 心跳超时heartbeat timeout机制来触发 Leader 选举：
未提交日志 已提交日志
集群中只有 Leader 对外提供服务：
当 Leader 在接收到命令之后，首先会将命令转换为一条对应的 日志记录log entry，并追加到本地的日志中。然后调用 AppendEntries 将这条日志复制到其他节点的日志中。
当日志被复制到过半数节点上时，Leader 会将这条日志中包含的命令 提交commit状态机执行，最后将执行结果告知客户端。
使用 过半数majority机制来处理脑裂：
保证新的 Leader 拥有所有已经提交的日志
Leader 只主动提交自己任期内产生的日志
一致性算法的本质：一致性与可用性之间的权衡。
Raft 的优点：Single Leader 的架构简化日志管理
Raft 的缺点：对日志的连续性有较高要求
限于篇幅限制，本文只展示了 Raft 算法大致的轮廓。
此前在学习算法的过程中，使用 Java 实现了一个简化版的 Raft 协议：rafting
代码忠实于论文原文，包含了其中的众多算法细节，希望对各位学习 Raft 的朋友有所帮助。
标签：cli 独立 时机 代码 follow tables and leader ble
原文地址：https://www.cnblogs.com/buttercup/p/12903126.html
