分布式数据库赛道 — 核心技术难点

基于 6 个项目（OpenTenBase / CockroachDB / TiDB / YugabyteDB / Citus / Vitess）的源码和架构调研 调研时间：2026-06-22

难点总览

1. 分布式事务一致性

核心矛盾：想象你和朋友同时在两个 ATM 上操作同一个账户——一个存钱一个取钱。单机数据库用锁就能保证不出错，但在分布式环境下，数据分散在不同机器上，如何保证”要么全做完，要么全没做”？做得太严格（强一致性），每笔交易都要多台机器达成共识，速度慢；做得太松（最终一致性），用户可能看到中间态（钱存了但余额没变）。

真实案例：CockroachDB 的 Parallel Commits（docs/tla-plus/ParallelCommits/ParallelCommits.tla）用 TLA+ 数学证明了其并行提交协议的正确性。传统两阶段提交需要两轮网络往返（prepare → commit），CockroachDB 把 commit 决策与最后一批写操作合并在一轮中完成。OpenTenBase 的 GTM（src/gtm/main/gtm_txn.c）则采用中心化的全局事务 ID 分配器，简化了一致性保证但引入了单点风险和性能瓶颈。

根本难点：FLP 不可能定理——在异步网络中，一致性、可用性和分区容忍性不可能同时满足。每个项目选择了不同的 trade-off。

2. 分布式查询优化

核心矛盾：想象一个旅行规划问题——你要从北京经过多个城市到达上海，可能的路线组合有成千上万种。单机数据库的查询优化已经是 NP-Hard 问题，分布式环境下还需要考虑：数据在哪些节点上、网络传输成本多大、哪些操作可以下推到存储节点。搜索空间呈指数增长，但用户等不了。

真实案例：TiDB 的 Cascades 框架（pkg/planner/cascades/cascades.go）实现了经典的 Cascades 搜索框架，含 Memo、规则引擎和任务调度器。Citus 的五层渐进式规划（planner/README.md）采用 Fast-path Router → Router Planner → Modification Planning → Recursive Planning → Logical Planner 的分层回退策略，大部分 OLTP 查询在前两层就被快速处理。

根本难点：统计信息的不完整性。优化器需要估算每个操作的行数来选择最优计划，但在分布式环境下全局统计信息总是滞后的。

3. 数据分片与再均衡

核心矛盾：想象一个图书馆要把书从旧书架搬到新书架上重新排列。搬书的过程中，读者还在不断来借书还书。你不能把所有书架都关了再搬，但搬的过程中书的位置在变化，目录还得保持准确。

真实案例：CockroachDB 的 Range 自动分裂（pkg/kv/kvserver/split_queue.go）通过 load_based_splitter.go 选择最优的分裂点。Vitess 的 VReplication（go/vt/wrangler/resharder.go）在后台复制数据到新分片，切换流量时原子地更新路由规则。

根本难点：移动数据的同时保持一致性。CockroachDB 通过 Raft 的 learner 机制解决：先在目标节点创建一个 learner 副本同步数据，数据追上后原子切换。但边界情况极其复杂。

4. 全局时钟与因果序

核心矛盾：想象世界各地的人同时参加一个在线拍卖——纽约和东京的竞拍者几乎同时出价，谁先谁后？物理时钟有误差、网络有延迟，如何定义一个全局公认的”先后顺序”？

真实案例：CockroachDB 使用 HLC + Uncertainty Interval（pkg/storage/testdata/mvcc_histories/uncertainty_interval*），当一个事务读到的值的时间戳落在自己的不确定区间内，事务需要以更高的时间戳重启。YugabyteDB 的 Hybrid Time（src/yb/common/hybrid_time.h）纯软件实现，代价是不确定窗口更大。

根本难点：光速限制——信息从一个数据中心传到另一个至少需要几毫秒，无法消除。这是一个”花钱买硬件精度”还是”花性能买软件容错”的经典 trade-off。

5. HTAP 双引擎隔离

核心矛盾：想象一家餐厅的厨房——前台点菜（TP 事务）和后台盘点库存（AP 分析）共用一个厨房。如果盘点员占用了所有灶台，做菜就停了；如果做菜优先，库存数据永远对不上。

真实案例：TiDB 通过 Raft Learner 将 TiKV 数据异步复制到 TiFlash，Learner 不参与投票不影响 TP 写入延迟，但 AP 查询有秒级延迟。OpenTenBase 的行存和列存运行在同一个 Datanode 上，简化了数据同步但资源隔离更困难。

根本难点：两种 workload 的资源模型完全不同。TP 需要低延迟小数据量随机读写；AP 需要高吞吐大数据量顺序扫描。它们对 CPU cache、内存带宽、IO 调度的需求几乎完全冲突。

6. 共识协议工程化

核心矛盾：Raft 论文只有 18 页，但工业级实现需要处理论文没提到的无数细节——leader 选举风暴、日志压缩时机、慢 follower 的流控、配置变更的安全性。

真实案例：CockroachDB 的 pkg/raft/ 引入了 Fortification 机制和 StoreLiveness 替代传统心跳检测。YugabyteDB 的 src/yb/consensus/multi_raft_batcher.cc 实现了多 Raft 组的消息批处理——当一个节点管理数百个 tablet 时效率至关重要。

根本难点：正确性验证。CockroachDB 用 TLA+ 形式化验证（docs/tla-plus/）、大量 data-driven 测试和混沌测试（pkg/kv/kvnemesis/）来建立信心，但依然不断发现边界 bug。

7. 分布式 DDL

核心矛盾：单机数据库加一列只需修改一个元数据文件；分布式数据库需要在所有节点上同步执行变更——期间不能中断正在执行的查询，不能让不同节点看到不同的表结构。

真实案例：CockroachDB 采用 Google F1 的渐进式 schema 变更协议——一次变更经过 delete-only → write-only → public 多个阶段。TiDB 在 pkg/ddl/ 目录实现异步 DDL 框架，通过 owner 选举确保同一时刻只有一个 TiDB 节点执行 DDL。

根本难点：版本兼容窗口。在变更传播期间，集群中同时存在新旧两个版本的 schema，需要保证相邻阶段的 schema 相互兼容。

8. 连接管理与执行调度

核心矛盾：每个分布式查询可能需要与多个 worker 节点通信。维护太多连接浪费资源，太少又成瓶颈。

真实案例：Citus 的 Adaptive Executor（adaptive_executor.c）采用 Slow Start 算法动态调整连接池大小，通过 WaitEventSet 多路复用所有连接的 IO 事件。Vitess 的 ScatterConn（scatter_conn.go）通过 health check 动态选择最健康的 tablet 副本。

根本难点：长尾延迟放大。一条跨 N 个分片的查询，总延迟取决于最慢的那个分片。当 N 增大时，”至少有一个分片慢”的概率急剧增加。

9. SQL 兼容性的完整度

核心矛盾：用户期望”无缝迁移”——把 MySQL/PG 的 SQL 原封不动地跑在分布式数据库上。但分布式环境对某些 SQL 特性天然不友好（如全局排序、跨分片 JOIN、存储过程中的事务控制）。

真实案例：Vitess 的 Gen4 Planner（go/vt/vtgate/planbuilder/operators/）展示了在中间件层重新实现 SQL 语义的复杂性。TiDB 选择自研 parser（pkg/parser/parser.y）获得完全控制权但承担所有兼容性 bug。

根本难点：语义边界模糊。SQL 标准有数千页，MySQL 和 PG 各自还有大量方言特性。用户经常依赖未文档化的行为。

10. 故障检测与自动恢复

核心矛盾：检测太快容易误判（网络抖动当成节点故障），检测太慢真正的故障迟迟得不到处理。

真实案例：CockroachDB 的 Store Liveness（pkg/raft/raftstoreliveness/）实现了比传统心跳更精细的存活检测——不仅检测节点是否在线，还评估其存储层的健康状态。

根本难点：无法区分慢和死。一个节点的响应时间从 1ms 变成 10s，它是”慢了”还是”挂了”？这个判断本质上不可能完美解决。

11. 多租户隔离

核心矛盾：多个租户共享同一个集群。如何保证一个”大户”的重查询不影响其他租户？完全隔离意味着资源浪费，完全共享意味着互相干扰。

真实案例：CockroachDB 的 pkg/multitenant/ 实现 SQL 层多租户隔离，tenantrate/ 基于 token bucket 限流。Citus 的 schema_based_sharding.c 支持按 schema 分租户。

根本难点：共享存储层的隔离。底层的 LSM-Tree compaction、Raft 日志同步等操作仍然是所有租户共享的。

12. 全局死锁检测

核心矛盾：分布式环境下等待图分散在多个节点上，需要收集全局信息才能检测环——收集频率太高浪费带宽，太低死锁长时间无法解除。

真实案例：YugabyteDB 的 src/yb/docdb/deadlock_detector.cc 每个 tablet 维护本地等待关系，周期性汇报给 coordinator 构建全局等待图。Citus 通过 WaitGraph 结构在协调节点上构建全局等待图。

根本难点：信息收集的一致性。由于网络延迟，不同节点收集到的等待关系可能属于不同时刻——可能导致误检（phantom deadlock）。

领域难度总结

分布式数据库是计算机科学中工程复杂度最高的领域之一。从源码调研可以看到：CockroachDB 的 pkg/ 目录下有 15,000+ 文件，TiDB 的 pkg/planner/ 有完整的 Cascades 优化器 + 40+ 优化规则，即使是”最简单的” Citus 扩展模式也有 5,359 行的 adaptive_executor.c。

对犀牛鸟 2026 的参与者来说，理解这些难点不是为了从零解决它们，而是为了找到切入点、避免踩坑、站在巨人肩上。CockroachDB 的 TLA+ 验证、Citus 的 Planner README、TiDB 的 Cascades 实现，都是可以直接学习和复用的宝贵资源。