TiDB 内核解剖室SECTION 01

把一个分布式写入,拆成 6 步给你看 —— Multi-Raft 日志复制与多数派提交

1024 TiDB AIGC 黑客松 · 参赛作品 v0.2
TiDB / 客户端 SQL → KV 写入 TiKV-1 LEADER RAFT LOG TiKV-2 FOLLOWER RAFT LOG TiKV-3 FOLLOWER RAFT LOG
已追加 · 未提交
已应答 ACK
已提交 Committed
已应用 Applied
副本离线
本节口径与参数说明(技术解读准确性依据)
  • TiDB 的存储层 TiKV 采用 Multi-Raft:数据按 Range 切分为 Region,每个 Region 的多个副本分布在不同 TiKV 上,构成一个独立的 Raft Group,各自选主、各自复制。
  • 默认 3 副本,多数派公式 quorum = ⌊n/2⌋ + 1,即 2。因此 3 副本可容忍 1 个副本故障而写入不中断 —— 这是 RPO=0 与高可用的机制来源。
  • 副本数低于多数派时集群 停止写入而非写入不一致数据,即选择 CP 而非 AP。这是"宁可不可用,不可不一致"的取舍。
  • 复制是 并行而非串行,因此写入延迟不随副本数线性放大;Follower 侧 Apply 是异步的,允许副本间短暂可见性差异,但日志已一致。

口径与参数来源(已核验 · 2026-09-16 · TiDB 官方文档 stable 线 / release-8.5)
· Region 分裂阈值 coprocessor.region-split-size 默认 256MiB(v8.4.0 之前为 96MiB;官方标注为估算值);允许超出阈值 region-split-check-diff = Region 大小的 1/16。
· 心跳间隔 = raft-base-tick-interval(1s) × raft-heartbeat-ticks(2) = 2s;选举超时 = 1s × raft-election-timeout-ticks(10) ≈ 10s;Leader 租约上限 raft-store-max-leader-lease = 9s。
· Region 副本数由 PD replication.max-replicas 控制,默认 3(1 leader + 2 follower);官方明确"在一般情况下,PD 只会保证多个副本不落在一个节点上",副本调度的基本操作为增加副本 / 删除副本 / 转移 Leader。
· 官方未给出"Leader 故障到新 Leader 就绪"的端到端时长,故本台只呈现 tick 机制,不写端到端时长。
· 来源:TiKV 配置文件描述、PD 配置文件描述、TiDB 数据库的调度(docs.pingcap.com/zh/tidb/stable)。

以上带虚线的条目均可点击,查看官方原文、适用版本与文档链接 —— 琥珀色虚线表示"官方未列明,因此本作品一个字都不写"。

系列导航:01 Multi-Raft 日志复制 · 02 Region 分裂与 PD 调度 · 03 分布式事务 2PC · 04 向量搜索与 HNSW 索引

当前步骤
STEP 01 / 06
客户端发起写入
点击下方"下一步"开始。
集群状态
可用副本3 / 3
多数派 quorum2
写入状态正常
已提交位点Index 4
破坏性演示 · 亲手把它做坏

先杀 1 个 Follower,再把写入跑一遍 —— 你会发现它照样成功。
Leader 故障需触发 Raft 重新选举,属本系列 05 号演示台主题(可亲手杀掉 Leader 看选举)。