前言

在分布式系统中，一致性共识协议是保证多个节点达成同一状态的核心技术。虽然 Paxos 提供了理论基础，但它实现复杂、理解困难。为此，Raft 协议应运而生，目标是更易理解、实现且具备等价安全性。

如今，许多主流系统如 etcd、Consul、TiKV 都基于 Raft 构建，是工程实践中最受欢迎的共识协议之一。

定义

wiki 定义如下：

Raft is a consensus algorithm designed as an alternative to Paxos, with the goal of being more understandable.

一句话：Raft 是一种用于构建高一致性分布式系统的共识协议，以简单易懂著称。

工作原理

一句话：通过选举 Leader 并由其统一处理客户端请求，实现复制日志并达成一致状态。

Raft 分为三个主要阶段：

  1. Leader 选举 节点间通过心跳检测故障并发起投票选出一个 Leader。

  2. 日志复制（Log Replication） 所有写入请求由 Leader 接收并复制到 Follower，半数以上确认后提交。

  3. 安全提交（Commit） Leader 确认多数节点写入后，提交并通知 Follower 应用状态变更。

角色分类：

  • Leader：唯一处理客户端请求。
  • Follower：被动响应 Leader 或 Candidate。
  • Candidate：在选举时发起投票的节点。

属性与指标

Raft 关注以下属性与性能指标：

  1. 线性一致性（Linearizability） 所有客户端看见的数据变化顺序一致。

  2. 容错性（Fault Tolerance） 能容忍少数节点宕机（2f+1 中允许 f 节点失败）。

  3. 可恢复性 节点崩溃后重启可恢复状态，日志持久化保障一致性。

  4. 选举安全性 同一任期只能有一个 Leader。

  5. 高可用性 Leader 故障后快速重新选举保持服务不中断。

  6. 日志压缩 通过快照和日志截断减少存储压力。

类型

日志复制机制

  1. AppendEntries：Leader 向 Follower 发送日志条目。
  2. Leader Commit Rule：Leader 只有在某日志条目被大多数节点存储时，才可提交该条目。
  3. Log Matching：相同任期和索引的日志应保证内容一致。

选举机制

  1. 随机超时触发选举
  2. 投票请求（RequestVote）
  3. Leader 心跳（Heartbeat）保持统治

日志压缩方式

  1. 快照（Snapshot）
  2. InstallSnapshot RPC
  3. 日志截断

应用场景与程序关系

场景 是否适用 Raft 说明
分布式协调服务 ✅ 适合高一致性系统，如分布式锁
主从切换与容灾 ✅ 自动 Leader 选举
分布式 KV 存储 ✅ 一致性写入，事务支持
异步副本系统 ❌ 不适合 eventual consistency 场景
大规模区块链 ❌ 不适合开放网络的共识需求

编程关系：

  1. 推荐使用已有实现：如 etcd（Go 实现）、Consul（Go）、Hashicorp Raft。
  2. 适用于小规模强一致集群：如配置中心、数据库集群等。
  3. 写入延迟受限于同步复制：网络 RTT 会直接影响写性能。

常用基于 Raft 的系统

  1. etcd：Kubernetes 的核心组件，保存集群状态。
  2. Consul：服务发现与配置管理平台。
  3. TiKV：分布式事务型 KV 数据库，TiDB 存储引擎。
  4. Rqlite：基于 SQLite 的分布式数据库。
  5. CockroachDB（部分借鉴）：NewSQL 数据库，参考 Raft 设计。

参考