案例研究：Spanner、DynamoDB、Kafka 与 TiDB
本文基于模型知识整理（生成时未联网核对），关键结论建议对照经典文献复核。
一句话定义
用前文的概念框架（复制、一致性、共识、分区、事务、时间）解剖四个工业级系统：Spanner 用专用时钟换全球外部一致，DynamoDB 用可调 quorum 换永远可写，Kafka 用分区日志换极高吞吐流，TiDB 用 Multi-Raft + 中心时间戳在普通机房提供强一致分布式 SQL——四个系统是同一组概念权衡的四种答案。
为什么重要
概念只有落到真实系统上才算掌握。这四个系统分别代表"时间驱动""AP 倾向""吞吐优先""通用 SQL"四条路线，覆盖了前面每个知识点的实际形态；读懂它们的论文与取舍，就具备了推断任何新系统设计意图的能力。
前置知识
kp-003、kp-011~015、kp-019、kp-023、kp-025、kp-027。
核心概念：四系统的设计决策表
| 维度 | Spanner (2012) | DynamoDB (2007/2012) | Kafka | TiDB |
|---|---|---|---|---|
| 复制与容错 | Paxos 组 | 无主 quorum（Dynamo 血统） | 分区多副本 ISR | Multi-Raft |
| 一致性 | 外部一致（最强） | 可调（最终~强） | 分区内顺序 | 快照隔离/可串行化 |
| 时间来源 | TrueTime 硬件 | 本地时钟（LWW/版本向量） | 无（逻辑 offset） | 中心 TSO |
| 分区 | 目录级自动分片 | 哈希+range | 显式 partition | Region 动态分裂 |
| 事务 | 2PC+Paxos+commit wait | 单行原子，事务有限 | 无（Kafka 事务为流处理） | Percolator 改造 |
| 典型代价 | 写延迟（commit wait）、专用设施 | 冲突处理交应用 | 无全局顺序、无二级索引 | TSO 单点依赖与跨中心 RTT |
原理与机制
Spanner——用硬件驯服时间：全球部署的 Paxos 组提供副本容错；事务提交时间戳来自 TrueTime 区间（GPS+原子钟，误差窗口 ~几毫秒）。两阶段提交（kp-023）跨组协调，协调者在返回前 commit wait——等到"确保任何副本的时钟都已越过提交时间戳"才确认，从硬件时间差里买到外部一致性（先提交的事务先于后提交者被观察）。教训：时间正确性可以用钱和延迟买。
DynamoDB——可用性优先的演化：原始 Dynamo 论文（2007）是 AP 教科书：quorum + 向量时钟 + sloppy quorum + hinted handoff + Merkle 反熵（kp-010/014/015 全集）。AWS 商业化为 DynamoDB 后逐步收敛：加入强一致的"线性一致读"选项、多事务（事务项上限 100）、自适应容量——说明商业系统最终会在 AP 原型上补回 C，因为应用开发者不想处理冲突。
Kafka——为吞吐重新定义一致性：放弃"存储任意数据 + 事务"的包袱，只做追加日志：分区（kp-025）+ 顺序写磁盘 + 零拷贝 + 页缓存 ⇒ 单机百万级消息/秒。副本机制（ISR：与 leader 保持同步的副本集合）用"ISR 收缩即降级"在一致性与可用性间切换（unclean.leader.election=false 时宁可不可写也不丢已确认数据，CP 倾向）。元数据管理从 ZooKeeper 迁往内嵌 Raft（KRaft，kp-020）——外部协调被内部共识取代的典型演进。
TiDB——开源世界的强一致分布式 SQL：TiKV 按 Region（~96MB）分裂，每个 Region 一个 Raft 组（kp-019/025/026 的 Multi-Raft）；全局时间戳由 PD 的中心 TSO 统一发号（kp-027 的路线二），事务层改造 Google Percolator（两阶段 + 主键锁记录），默认快照隔离、可选悲观事务。教训：无专用时钟硬件时，中心化发号是简单可靠的折衷，代价是 TSO 的可用性与跨地域 RTT。
实例或案例
把四个系统放回真实选型场景，验证"概念 → 决策"的推导路径：
- 全球库存强一致（跨境电商）：多地域写、要求"上海提交的扣减，法兰克福立刻不可重复卖"——对应 Spanner 路线：外部一致性 + TrueTime/commit wait。若无专用时钟，退而求其次是 TiDB 式单地域强一致 + 异地只读容灾。
- 购物车与用户配置（读写比 100:1）：单用户低冲突、可用性优先——对应 DynamoDB 路线：最终一致 + 条件写（乐观锁单行事务），冲突面天然小，无需全局共识。
- 订单事件流水（峰值 50 万条/秒）：只追加、按序消费、供下游批流消费——对应 Kafka 路线：分区保序 + ISR 副本；不要试图把它当库存库用。
- 公司级 HTAP 中台（事务 + 报表）：MySQL 分库分表已到极限、要保留 SQL 生态——对应 TiDB 路线：Multi-Raft 水平扩展 + 行列混合；先评估 TSO 延迟与运维成本是否可接受。
这四个案例可直接当作面试与架构评审的推演模板：先问"一致性/可用性/延迟三者谁必须赢"，再对照上表选路线，最后列出为该路线要付的代价（commit wait 延迟 / 冲突处理复杂度 / 顺序模型的局限 / TSO 依赖）。
常见误区
- 误区一："新系统一定比旧系统先进"。DynamoDB 至今保留大量 Dynamo 原始设计的影子，而 Spanner 的思路（2012）至今无人低成本复刻——评估系统看"对目标场景的取舍是否合理"，不看论文年份。
- 误区二："Kafka 是数据库"。它没有任意查询与强事务语义，拿它当存储主库会在"回放语义/ retention"上踩坑；定位是日志与流管道。
- 误区三："TiDB 的 TSO 是单点故障源"。PD 以 etcd（Raft）保 TSO 高可用；单点的是发号顺序而非可用性——区分"顺序单点"与"可用性单点"是读分布式 SQL 架构的关键。
与其他知识点的关系
- 几乎全部：本条是知识库前 31 条的综合应用场。
- kp-033：这些系统的历史故障（Jepsen 报告）是测试与验证一节的主要素材。
自测题
- Spanner 的 commit wait 具体在等什么？
答：等 TrueTime 区间的"最晚可能时间"过去，确保任何副本（含异地）读到的提交时间戳都已真实发生，从而跨地域也满足外部一致性。
- Kafka 的 ISR 机制如何体现 CP/AP 切换？
答：副本落后超阈值即被移出 ISR；ISR 不足 min.insync.replicas 时拒绝写入（保一致性、牺牲可用性）；允许 unclean 选举则反过来——开关即两种模式的切换器。
- TiDB 为什么选择中心化 TSO 而非 HLC？
答：单机房场景中心发号实现简单、单调可靠；代价只是每事务一次 TSO 往返，比 HLC 的因果维护更易验证正确性。
延伸阅读
- Corbett 等, "Spanner"（OSDI 2012）；DeCandia 等, "Dynamo"（SOSP 2007）。
- Kreps 等, "Kafka: a Distributed Messaging System for Log Processing"（NetDB 2011）与 KIP-500（KRaft）。
- Huang 等, "TiDB: A Raft-based HTAP Database"（VLDB 2020）；Peng & Dbitsky, "Large-scale Cluster Management at Google with Borg" 之外的 Percolator（OSDI 2010）。