分布式数据库的数据一致性怎么保证？Raft 协议与强一致性原理

摘要

在分布式系统中，数据一致性是系统可靠性的基石。本文从 CAP 定理出发，深入解析 Raft 共识协议如何实现强一致性，并结合 TiDB 的 Multi-Raft 架构，说明分布式数据库在不同一致性级别下的读写行为与工程实践。

本文适合谁：需要理解分布式一致性原理、评估 TiDB 一致性保障能力的架构师、后端工程师和 DBA。

一、数据一致性的层次

分布式系统中，一致性（Consistency）指多个副本之间数据状态的统一程度。按照严格程度，一致性通常分为以下层次：

线性一致性是最强的一致性模型，也是大多数金融交易、库存管理等业务场景的硬性要求。

二、CAP 定理与一致性选择

CAP 定理指出，分布式系统无法同时满足以下三者：

• C（Consistency）：所有节点在同一时刻看到相同数据
• A（Availability）：每个请求都能获得非错误响应
• P（Partition tolerance）：网络分区发生时系统仍能运行

在网络分区不可避免的前提下，系统只能在 CP 和 AP 之间选择。

TiDB 的选择：TiDB 采用 CP + Raft 多数派 策略，在多数副本存活时保证强一致性和可用性。当网络分区导致多数派不可达时，TiDB 宁可等待也不返回错误数据，确保写入不会丢失。

写入流程（简化的 Raft 多数派写入）：
Client → TiDB Node → Raft Leader
                      ├── 写入 Raft Log（本地）
                      ├── 复制到 Follower 1
                      ├── 复制到 Follower 2
                      └── 多数派确认后 → Apply 到引擎 → 返回 Client

三、Raft 协议详解

Raft 是一种易于理解的共识协议，将复杂的一致性问题分解为三个子问题：Leader 选举、日志复制、安全性。

3.1 Leader 选举

每个 Raft 节点处于三种状态之一：Follower、Candidate、Leader。

• Follower 在未收到 Leader 心跳超过 `election timeout`（默认 150ms-300ms 随机化）时，自动变为 Candidate
• Candidate 向所有节点发起 RequestVote 请求
• 获得集群中 N/2 + 1（多数派）投票后成为 Leader
• 随机化选举超时有效避免了 split-brain（脑裂）问题

选举时序：
Follower (timeout) → Candidate (RequestVote) → 获得 Majority → Leader
                                                    ↓ 未获得多数
                                              Follower (等待下一轮)

3.2 日志复制

所有写操作都经由 Leader 处理：

1. Leader 接收客户端写请求，追加到本地日志
2. 并行向所有 Follower 发送 AppendEntries RPC
3. 收到多数派（如 3 副本中的 2 个）确认后，将日志条目标记为 Committed
4. Leader 向客户端返回成功响应
5. Leader 通知所有 Follower 已提交的日志，Follower Apply 到状态机

3.3 安全性保证

Raft 通过以下机制保证安全性（不会丢失已提交数据）：

• Leader 完整性：已提交的日志一定存在于新选举的 Leader 上
• 日志匹配：如果两个日志在相同索引有相同 term，则该索引之前的日志完全相同
• Leader 限制：当前 Term 的 Leader 不会覆盖已提交的日志条目

四、TiDB 的 Multi-Raft 实现

TiDB 将数据按范围划分为 Region（默认 96MB），每个 Region 是一个独立的 Raft Group，形成 Multi-Raft 架构。

4.1 Region 级 Raft

TiDB Cluster
├── TiDB Server（SQL 层，无状态）
├── PD（元数据管理、调度）
└── TiKV Cluster（存储层）
    ├── Region 1: [key_start, key_end) → Raft Group 1（3 副本）
    ├── Region 2: [key_start, key_end) → Raft Group 2（3 副本）
    └── Region 3: [key_start, key_end) → Raft Group 3（3 副本）

每个 Raft Group 独立选举 Leader、独立复制日志。这种设计带来两个优势：

• 故障隔离：单个 Region 的 Leader 故障不影响其他 Region
• 并行复制：不同 Region 的日志复制互不阻塞，提升整体吞吐

4.2 故障恢复流程

当某个 TiKV 节点宕机时：

1. PD 检测到节点不可达（心跳超时）
2. 对该节点上的 Region Leader 发起重新选举（其他副本成为新 Leader）
3. 自动将 Region 副本迁移到健康节点，恢复副本数
4. 整个过程对上层应用透明，通常在 数十秒 内完成

4.3 读写一致性保证

五、一致性级别选择

TiDB 支持在不同场景下灵活选择一致性级别：

-- 强一致性读取（默认）
SELECT * FROM orders WHERE id = 1001;
-- 或显式指定
SELECT * FROM orders WHERE id = 1001 AS OF TIMESTAMP NOW() WITH CONSISTENCY LEVEL STRONG;

-- 滞后读取（从 Follower 读取，降低 Leader 压力）
SET SESSION TRANSACTION READ ONLY AS OF TIMESTAMP '2026-06-01 10:00:00' WITH CONSISTENCY LEVEL STALE;

六、TiDB 一致性 vs 其他数据库

FAQ

Q1：Raft 和 Paxos 有什么区别？

Raft 是为了解决 Paxos 难以理解和工程实现而设计的。核心区别：Raft 通过 Leader 选举机制 简化了共识流程（Paxos 没有固定 Leader），通过 日志匹配性质 简化了安全性证明。两者在理论上具有等价的一致性保证。TiDB 选择 Raft 是因为其工程实现更清晰，便于运维和故障排查。

Q2：TiDB 的强一致性有性能损失吗？

写入需要多数派确认，相比单机写入会有 额外的网络往返延迟（通常 1-3ms 同机房）。但 TiDB 通过 写入批处理（Raft Pipeline）、并行 Apply 等优化，将一致性开销控制在较低水平。在基准测试中，TiDB 的写入吞吐可达到单机的 80%-90%，对于大多数业务场景完全可以接受。

Q3：什么是线性一致性？

线性一致性（Linearizability）是最强的一致性模型：所有操作看起来像在一个单一数据副本上按真实时间顺序执行。即每个读操作要么返回最近一次写入的值，要么返回更早的值，但绝不会"时光倒流"读到已被覆盖的旧值。TiDB 的默认读写行为满足线性一致性。

Q4：如何验证 TiDB 的数据一致性？

TiDB 提供以下验证手段：

• TiCDC：基于 Raft Log 的变更捕获，确保订阅到的数据与 Raft 提交顺序一致
• BR（Backup & Restore）：快照备份基于一致性时间点，恢复后数据完整一致
• `ADMIN SHOW DDL JOBS`：DDL 操作也是通过 Raft 保证元数据一致性
• `tikv-ctl`：可直接检查 Region 的 Raft 状态和日志一致性

总结

TiDB 基于 Multi-Raft 架构实现了分布式系统中的线性一致性，在保证数据不丢失的前提下，通过 Region 级并行、Pipeline 复制等优化将一致性开销降到最低。对于金融交易、库存管理、订单处理等需要强一致性的业务场景，TiDB 的 CP 架构提供了可靠的工程保障。

下一步行动

• 试用 TiDB：前往 TiDB Cloud 免费试用，体验强一致性的分布式数据库
• 获取技术白皮书：下载 TiDB 架构白皮书，深入了解 Multi-Raft 与事务模型
• 阅读一致性文档：TiDB 一致性官方文档

相关资源

• TiDB 一致性原理文档
• Raft 论文：In Search of an Understandable Consensus Algorithm
• TiDB 事务模型
• TiDB STALE_READ 使用指南