CockroachDB与YugabyteDB分布式数据库对比

可视化演示

对比CockroachDB对等架构与YugabyteDB分层架构、展示Range/Tablet分片与Raft复制机制、以及多区域全球部署策略，切换模式查看不同维度对比。

架构演进：从独灶小馆到连锁集团

想象你家巷口有家“独灶小馆”：就一口灶、一位大厨、一个收银台。生意一好，排队两小时——性能到顶了；大厨一感冒，全店歇业——单点故障。这就是传统单机数据库的日常：CPU、内存、磁盘就是那口灶的“火力上限”，想扩容只能换更大的灶（纵向扩展），可灶台再大也有物理极限。

为了让更多客人进门，餐饮业先想到“厨师抄菜谱”：把菜谱复制给几个徒弟，客人多了可以去徒弟那桌吃同样的菜（主从复制、读写分离），但写菜谱仍只能师父来，徒弟只能应付读。后来又想到“分桌”（分库分表）：把菜单按菜系切给不同厨师，可切得不好就有人忙死有人闲死，而且跨桌拼菜（跨库 JOIN）几乎做不了。

云原生分布式数据库走的是“连锁集团”路线：把数据自动切成许多小份（分片），散布在很多普通服务器（节点）上；哪台机器负载高，数据就自动搬走（自动均衡）；哪台机器坏掉，副本自动顶上（故障自愈）。它不依赖一台“超级大厨”，而是用一群普通厨师组成永不歇业的团队。这也是它与“分库分表中间件”的本质区别：分片、复制、事务都是引擎内置的，对 SQL 透明。

所以连锁集团的目标不是把某一家店开得更大，而是让每个档口都足够快、足够稳，还能随时补位。理解了这条“短板公式”，你就明白分布式数据库真正追求的不是单机更快，而是让最慢的节点也永不掉链子。

CockroachDB架构：全能的“不垮食堂”

Cockroach 这个名字就是“蟑螂”，寓意怎么都打不死。它的每家分店（节点）都是全能店员：点单、备料、掌勺样样在行。最关键的是，所有分店共用一本“电子总台账”——每种原料都按“编号 + 状态”记录（Key-Value 存储），任何店员查同一个编号，得到的记录都一致。

CockroachDB 用 Go 语言写成，所有数据——不管是表、索引还是分区——最终都落在一个统一的、按键排序的分布式 Key-Value 存储里。它以约 64MB 为单位把数据切成许多 Range，每个 Range 默认保存 3 份副本，副本之间用 Raft 共识协议同步：写入必须得到多数副本确认才提交。读取由每个 Range 的“租约持有者”（Leaseholder）负责，它相当于分店的值班店长。SQL 层则是“翻译官”：把 SELECT、JOIN 翻译成对 KV 的读写操作，再根据 Key 范围路由到正确的 Range。

全能店员 + 总台账 + 投票制，构成了“不垮食堂”的生存哲学：任何分店突然消失，其余分店一合计（选举新 Leader）就能继续营业，账目一分不少。正因如此，CockroachDB 在跨机房灾难场景下以“不丢数据”著称。

YugabyteDB架构：分工明确的“伶鲸餐厅”

“伶鲸餐厅”的聪明之处在于把前厅和后厨彻底分开：前厅服务生全部按一家著名餐饮学院（PostgreSQL）的教材培训，客人用熟悉的术语点单；后厨则有一套统一的“文档食谱”（DocDB），食材按文档式档案归档。前厅不懂后厨的仓库细节，后厨也不关心客人的口音。

YugabyteDB 用 C++ 编写，是典型的双层架构。上层是查询引擎：YSQL 直接基于 PostgreSQL 源码构建，提供 PG 的连线协议与大部分语法；另有 YCQL 提供 Cassandra 风格的宽表 API。下层是 DocDB 存储引擎：它在 RocksDB 之上扩展出文档模型，把一行数据按列组织成子文档。每个表按主键范围切成 tablet，每个 tablet 是一个独立的 Raft 小组，默认 3 副本。查询层负责 SQL 解析、优化与执行计划，存储层负责持久化、复制与分布式事务，两者通过 RPC 协作。

前厅专业（PG 语义原汁原味），后厨高效（文档存储善于压缩与扫描），各司其职——这正是 YugabyteDB“更懂 SQL”的结构根源：它不需要把每个 SQL 都翻译成 KV，而是让 PG 的成熟执行器直接跑在自己头上。

SQL兼容：用顾客熟悉的方言点菜

客人来自天南海北：有的讲“川话”（MySQL 习惯），有的讲“粤语”（PostgreSQL 习惯）。“不垮食堂”选择在总台装一个“粤语翻译器”——它自己按 PG 的协议和语法接待，但内核是自研的；“伶鲸餐厅”则直接雇了一批 PG 学院毕业的服务生——内核就是 PG 本尊。

CockroachDB 的 SQL 层是自研的，它实现了 PostgreSQL 的连线协议（wire protocol）和大部分常用语法，用 Go 从零重写，兼容策略是“常用功能优先”，边缘特性（部分窗口函数、类型转换细节）取决于具体版本。YugabyteDB 的 YSQL 则把 PostgreSQL 源码“搬进”自己的查询层，继承了 PG 的解析器、优化器和执行器，因此 psql、pg_dump、JDBC/psycopg 驱动和常用扩展的迁移成本更低。但无论选哪家，从 MySQL 迁过来都要改写方言：自增主键改成 SERIAL/IDENTITY，反引号改成双引号，ON DUPLICATE KEY 改成 ON CONFLICT。

顾客点菜越顺畅，翻台率越高。选型前拿现有 SQL 跑一遍“点菜测试”，比看宣传册上印着“兼容 PostgreSQL”五个字有用得多——毕竟服务生会说粤语，不代表他会背粤语诗词。

多区域部署：跨城连锁的就近供货

连锁要开到全国，顾客最烦“菜从外地送”。有两种玩法：加盟店各自为政（多集群异步复制，各城市数据不完全同步）；直营中央调度（一个全球大集群，副本按城市就近摆放，负责拍板的“店长”（Leaseholder/Leader）被派到离客人最近的分店）。但“就近”有物理极限——光速也救不了几千公里的距离。

CockroachDB 把部署策略做成了可配置项：区域表（regional table）让副本固定在特定区域，全局表（global table）牺牲写延迟换取各区域读都快；还有存活目标（survivability goals），控制整个区域故障还是单个可用区故障时服务不中断。它的“就近读”靠把 Leaseholder 放到读数区域实现，并支持 follower reads——用可容忍的陈旧读换更低的延迟。YugabyteDB 类似：通过优先可用区（preferred zones）控制 tablet leader 的位置，并提供 xCluster 异步复制用于跨云多集群容灾。强一致写必须凑齐多数派，跨区域时每一笔写都绕不开物理距离。

跨城生意的本质是选址：把“拍板的人”（Leader/Leaseholder）放到客人身边，多数派才能最快凑齐；把副本放得太远，再快的服务器也救不了网络延迟。

选型决策：老板的加盟评分表

老板要加盟，得先列权重：口味正宗（SQL 兼容）占 40%，抗揍（一致性）占 30%，出餐快（延迟）占 20%，加盟费与培训（运维生态）占 10%。两家都试吃打分，加权求和就是最终答案。没有“哪家更好”，只有“哪家更适合你的客群”。

关键差异盘点。事务模型：CockroachDB 默认可串行化隔离（serializable），用混合逻辑时钟为全局事务排序，跨区域提交后往往还要多等一个时间戳推进的往返，因此跨区写更慢；YugabyteDB 默认快照隔离（snapshot isolation），语义贴近 PostgreSQL 的常用模式，跨区写没有额外的全局时钟等待，但也提供可串行化选项。一致性：两者都是 Raft 强一致多副本复制，没有“谁更一致”的本质差别，差别在于默认隔离级别带来的跨区写成本和 PG 语义匹配度。生态：YSQL 内核就是 PG，扩展、迁移工具链更宽；CockroachDB 运维简单，单二进制部署，托管云服务成熟，PostGIS、CDC 等能力也有完整方案。

把“别人说好”翻译成“我的场景打分高”，答案自然浮现：追求极端强一致的全局事务与高可用，优先看 CockroachDB；追求 PG 生态平滑迁移、默认事务语义贴近传统业务，优先看 YugabyteDB。评分表一列，剩下的就是执行。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""mini_raft_compare.py: 模拟 Raft 多数派与分片热点, 辅助理解分布式选型"""import random  def quorum(n):    # Raft 法定多数: 超过一半才算数    return n // 2 + 1  def write_availability(replicas, fail_rate, trials=20000):    # 随机故障下, 写入能拿到多数确认的概率    ok = 0    for _ in range(trials):        alive = sum(            1 for _ in range(replicas) if random.random() > fail_rate        )        if alive >= quorum(replicas):            ok += 1    return ok / trials  def shard_tail_latency(keys, shards):    # 把 key 哈希到分片, 返回最热分片的负载占比    buckets = [0] * shards    for k in keys:        buckets[k % shards] += 1    total = len(keys)    return max(buckets) / total  def choose(weights, scores):    # 加权评分: 输出各方案的加权总分    return {        name: sum(w * s for w, s in zip(weights, sc))        for name, sc in scores.items()    }  def main():    random.seed(42)    print("== Raft 写入可用性模拟 ==")    for r in (3, 5):        for f in (0.1, 0.3):            print(f"replicas={r}, fail_rate={f}: "                  f"avail={write_availability(r, f):.4f}")     print("== 分片热点模拟 (简单取模哈希) ==")    keys = [random.randint(1, 20) for _ in range(10000)]    for shards in (10, 50):        hot = shard_tail_latency(keys, shards)        print(f"shards={shards}, 最热分片负载占比={hot:.3f}")     print("== 数据库选型加权评分 ==")    weights = (0.4, 0.3, 0.2, 0.1)  # 一致性, 生态, 性能, 成本    scores = {        "CockroachDB": (9, 7, 8, 6),        "YugabyteDB": (8, 9, 7, 7),    }    print(choose(weights, scores))  if __name__ == "__main__":    main()

1. return n // 2 + 1计算 Raft 法定多数，3 副本时返回 2，5 副本时返回 3。
2. alive >= quorum(replicas)存活副本数是否达到多数派，决定这次写入能不能提交。
3. random.random() > fail_rate用均匀随机数模拟一台机器是否故障，fail_rate 越高越容易挂。
4. buckets[k % shards] += 1模拟“取模哈希”路由：把 key 对分片数取余，映射到某个分片。
5. max(buckets) / total最热分片承载的流量占比，占比越高说明倾斜越严重、短板越明显。
6. sum(w * s for w, s in zip(weights, sc))加权求和：把一致性、生态、性能、成本四项得分分别乘权重后累加。
7. random.seed(42)固定随机种子，让每次运行结果一致，便于复现实验结论。

常见误区

面试题