Raft 协议

Posted 2021-02-18 buttercup

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Raft 协议相关的知识，希望对你有一定的参考价值。

Paxos 存在的问题

Paxos 算法的描述偏学术化，缺失了很多细节，没有办法直接应用于工程领域。实际工程应用中的分布式算法大多是 Paxos 的变种，验证这些算法的正确性也成为了一个难题。

举个例子：上一篇文章的最后介绍了一个应用 Paxos 算法的工程模型，这个模型存在明显的写性能瓶颈：

使用多主架构，写入冲突的概率高
每次更新操作都需要至少 2 轮以上的网络通信，通信开销大

为了提高这个模型的性能，仍需要在很多细节上做进一步调整，最终实现出来的算法已经和原始的版本的 Paxos 相去甚远。

为了解决以上问题，另一个高性能且易于理解的一致性算法横空出世：Raft

基本概念

Raft 算法基于 复制状态机Replicated State Machine模型，本质上就是一个管理 日志复制 的算法。

Raft 集群采用 Single Leader 架构，集群中有唯一的 Leader 进程负责管理日志复制，其职责有：

接受 Client 发送的请求
将日志记录同步到其他进程
告知其他进程的何时能够提交日志

复制状态机

技术图片

复制状态机的本质就是：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集群中每个进程只能担任其中一个角色：

Leader：发送心跳、管理日志复制与提交
Follower：被动响应其他节点发送过来的请求
Candidate：主动发起并参与选举

技术图片

Raft 进程间使用 RPC 的方式进行通信，实现最基础的共识算法只需两种RPC：

RequestVote：用于选举产生 Leader
AppendEntries：复制日志与发送心跳

/**
 * 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 个独立的子问题：

Leader 选举Election：Leader 进程失效后能够自动选举出一个新的 Leader
日志复制Replication：Leader 保证其他节点的日志与其保持一致
状态安全 Safety：Leader 保证状态机执行指令的顺序与内容完全一致

为了方便理解，下面结合动画进行介绍。

选举

技术图片

使用 心跳超时heartbeat timeout机制来触发 Leader 选举：

节点启动时默认处于 Follower 状态，如果 Follower 超时未收到 Leader 心跳信息，会转换为 Candidate 并向其他节点发起 RequestVote 请求。
当 Candidate 收到半数以上的选票之后成为 Leader，开始定时向其他节点发起 AppendEntries 请求以维持其 Leader 的地位。
Leader 失效之后停止发送心跳，Follower 的心跳超时机制又会被触发，开始新一轮的选举。