2025年10月08日·2 分钟
分布式 SQL 数据库：何时使用 Spanner、Cockroach、Yugabyte
了解什么是分布式 SQL，Google Spanner、CockroachDB 与 YugabyteDB 有何不同，以及哪些真实场景值得采用多区域强一致性的 SQL。
了解什么是分布式 SQL，Google Spanner、CockroachDB 与 YugabyteDB 有何不同，以及哪些真实场景值得采用多区域强一致性的 SQL。
“分布式 SQL” 是指看起来和传统关系数据库一样——表、行、连接、事务和 SQL——但设计为在一个集群上运行（通常跨多台机器和多个区域），并且仍然表现为一个逻辑数据库。
这种组合之所以重要，是因为它试图同时交付三件事：
经典 RDBMS（如 PostgreSQL 或 MySQL）在所有数据都集中在一个主节点时通常最易于操作。你可以通过副本扩展读取，但扩展写入和抵御区域性故障通常需要额外架构（分片、手动故障转移和谨慎的应用逻辑）。
许多 NoSQL 系统走了相反的路线：先考虑扩展和高可用，有时通过放宽一致性保证或简化查询模型来实现。
分布式 SQL 走的是中间路径：保留关系模型和 ACID 事务，但自动分布数据以应对增长和故障。
分布式 SQL 数据库为如下问题而生：
这也是为什么 Google Spanner、CockroachDB、YugabyteDB 常被评估用于多区域部署和持续在线服务的原因。
分布式 SQL 并不总是“更好”。你将接受更多移动部件和不同的性能现实（网络往返、共识、跨区域延迟），以换取弹性和扩展性。
如果你的工作负载能放在一个管理良好的单库并通过简单的复制满足需求，常规 RDBMS 会更简单、更便宜。只有当替代方案是自定义分片、复杂的故障切换，或业务要求强制性多区域一致性和高可用时，分布式 SQL 才体现价值。
分布式 SQL 目标是让数据库感觉像熟悉的 SQL 数据库，同时把数据存储在多台机器上（通常跨多个区域）。难点在于如何协调多台计算机，使它们表现得像一个可靠的系统。
每段数据通常会复制到多个节点（复制）。如果一个节点出现故障，另一个副本仍然可以提供读取并接受写入。
为了防止副本偏离，分布式 SQL 系统使用共识协议——最常见的是 Raft（CockroachDB、YugabyteDB）或 Paxos（Spanner）。从高层看，共识意味着：
这种“多数投票”赋予了你强一致性：一旦事务提交，其他客户端不会看到旧版本的数据。
没有单台机器能容纳所有数据，因此表被拆分为更小的块，称为分片/分区（Spanner 称为 splits；CockroachDB 称为 ranges；YugabyteDB 称为 tablets）。
每个分区都通过共识复制并放置在特定节点上。放置不是随机的：你可以通过策略影响它（例如，把欧盟客户的数据留在欧盟区域，或者把热点分区放在更快的节点上）。良好的放置可减少跨网络往返，使性能更可预测。
在单节点数据库中，事务通常可通过本地磁盘写入就完成提交。在分布式 SQL 中，事务可能触及多个分区——可能位于不同节点。
安全提交通常需要额外协调：
这些步骤引入了网络往返，这也是分布式事务通常会增加延迟的原因——尤其是当数据跨区域时。
当部署跨区域时，系统会尝试将操作“接近”用户：
这就是多区域平衡的核心：你可以优化本地响应，但跨长距离保持强一致性仍会付出网络成本。
在选择分布式 SQL 前，请先自查基础需求。如果你只有一个主区域、负载可预期、运维人手有限，常规关系型数据库（或托管的 Postgres/MySQL）通常是最快上线的简洁方案。通过只读副本、缓存和精细的索引设计，你通常能在单区域架构上走很远。
当下列之一（或多个）成立时，分布式 SQL 值得认真考虑：
分布式系统增加复杂性和成本。如果满足下面情形要谨慎：
如果你能对以下两项或更多回答“是”，分布式 SQL 很可能值得评估：
分布式 SQL 听起来像是“同时得到一切”，但真实系统会迫使你做出选择——尤其是在区域间无法可靠通信时。
把网络分区当作“区域间链路不稳定或断开”。在那一刻，数据库可以优先考虑：
分布式 SQL 系统通常倾向于为事务优先保证一致性。这是团队常常想要的——直到分区导致某些操作必须等待或失败为止。
强一致性 意味着一旦事务提交，任何后续读取都会返回该提交值——不会出现“某个区域认为成功而另一个区域未更新”的情况。这对以下场景至关重要：
如果你的产品承诺是“我们确认就是生效的”，强一致性是特性而非奢侈品。
两个实用行为很重要：
跨区域的强一致性通常需要共识（多数副本在提交前需同意）。如果副本分布在不同大陆，光速就成了产品的约束：每次跨区域写入都会增加几十到上百毫秒的延迟。
权衡很简单：更多的地理安全性和正确性，通常意味着更高的写入延迟，除非你精心选择数据存放位置和事务允许提交的地点。
Google Spanner 是 Google Cloud 上提供的分布式 SQL 数据库托管服务。它面向希望使用一个逻辑数据库并在节点与区域间复制数据的多区域部署。Spanner 支持两种 SQL 方言选项——GoogleSQL（原生方言）和兼容 PostgreSQL 的方言——因此可移植性取决于你选择的方言和应用依赖的功能。
CockroachDB 是一个目标是让熟悉 PostgreSQL 的团队感到亲切的分布式 SQL 数据库。它使用 PostgreSQL wire 协议并支持大部分 PostgreSQL 风格的 SQL，但并不是逐字节兼容 Postgres（某些扩展和边缘行为有所不同）。它既可以作为托管服务（CockroachDB Cloud）运行，也可以自建部署。
YugabyteDB 是一个提供 PostgreSQL 兼容 SQL API（YSQL）和额外 Cassandra 兼容 API（YCQL）的分布式数据库。与 CockroachDB 类似，它通常被那些想要 Postgres 开发体验同时又需要跨节点/跨区扩展的团队评估。它既有自托管也有托管服务（YugabyteDB Managed），常见部署涵盖单区高可用到多区域设置。
托管服务通常减少运维工作（升级、备份、监控集成），而自托管在网络、实例类型以及数据实际运行位置上提供更多控制。Spanner 最常以托管方式在 GCP 上消费；CockroachDB 和 YugabyteDB 常见于托管与自托管两种模式，包括多云和本地部署选项。
三者都支持“SQL”，但日常兼容性取决于方言选择（Spanner）、Postgres 功能覆盖（CockroachDB/YugabyteDB），以及你的应用是否依赖特定的 Postgres 扩展、函数或事务语义。
提前规划很重要：及早测试你的查询、迁移和 ORM 行为，而不是假设可以直接替换。
一个经典的分布式 SQL 适配场景是那些在北美、欧洲和亚太有客户的 B2B SaaS 产品——例如支持工具、人力资源平台、分析仪表盘或市场平台。
业务需求很直接：用户希望“本地应用”响应速度快，而公司希望有一个逻辑上始终可用的数据库。
许多 SaaS 团队面临混合需求：
分布式 SQL 可以通过按租户的本地化策略干净地建模：将每个租户的主数据放在特定区域（或一组区域），同时保持整个系统的模式和查询模型一致。这让你避免“每个区域一个数据库”的扩张，同时满足驻留要求。
为了让应用快速，通常目标是：
这很重要，因为跨区域往返主导用户感知的延迟。即便在强一致性下，良好的本地化设计也能保证大多数请求无需承担洲际网络代价。
技术收益只有在可运维的前提下才有意义。针对全球化 SaaS，要规划：
做得好，分布式 SQL 会让你有单一产品体验同时又感觉本地化——无需把工程团队拆成“欧盟堆栈”和“亚太堆栈”。
金融系统是“最终一致”会导致真实资金损失的地方。如果客户下单、支付被授权、余额被更新，这些步骤必须在同一时间点上达成一致——现在就要一致。
强一致性重要因为它防止两个不同区域（或服务）各自做出“合理”决策最终导致账目错误。
在典型工作流中——创建订单 → 保留资金 → 捕获支付 → 更新余额/账本——你希望保证：
分布式 SQL 适合此类场景，因为它在节点间（常常跨区域）提供 ACID 事务和约束，使得账本不变量在故障期间也能保持。
大多数支付集成需要大量重试：超时、webhook 重试和作业重处理常见。数据库应辅助实现重试的安全性。
实用做法是把应用层的幂等键与数据库强制的唯一约束配合：
idempotency_key。(account_id, idempotency_key) 上添加唯一约束。这样第二次尝试会成为无害的空操作，而不是重复收费。
促销活动和工资发放会产生突发写入（授权、捕获、转账）。使用分布式 SQL，可以通过增加节点来提升写入吞吐，同时保持一致性模型。
关键是要为“热点键”做规划（例如某个商户账号承载全部流量），并使用能分散负载的模式设计模式。
金融工作流通常要求不可变的审计轨迹、可追溯性（谁/什么/何时）和可预测的保留策略。即便不指明具体法规，也应假设需要：追加式账本条目、带时间戳的记录、受控访问，以及不会破坏审计性的保留/归档规则。
库存与预订看起来简单，直到多个区域服务同一稀缺资源：最后一张演出票、限量发售的商品，或某晚的酒店房间。
难点不在于读取可用性，而在于防止两个人几乎同时成功占用同一项资源。
在没有强一致性的多区域设置中，每个区域可能基于稍旧的数据短时间内都认定有库存可用。如果两个用户在这个窗口内在不同区域完成结账，两个交易都可能被本地接受，之后在合并时发生冲突。
这就是跨区域超卖的成因：不是系统“错误”，而是系统允许短暂分歧的事实。
分布式 SQL 往往在这里被选择，因为它能为写密集的分配操作强制单一权威结果——因此“最后一张票”真的只会被分配一次，即使请求来自不同大陆。
保留 + 确认：在事务中放置临时保留（reservation 记录），然后在第二步确认付款。
过期：保留应自动过期（例如 10 分钟），以防用户放弃结账导致库存被长期占用。
事务型 outbox：当预订确认时，在同一事务中写入“要发送的事件”行，然后异步把它发给邮件、履约、分析或消息总线——避免“已预订但未发送确认”的缺口。
要点是：如果你的业务不能容忍跨区域的重复分配，强事务保证就从技术细节变成了产品特性。
当停机代价高、无法接受不可预测的故障，并且希望把维护变成枯燥的常规工作时，分布式 SQL 非常合适。
目标不是“永不失败”，而是满足明确的 SLO（例如 99.9% 或 99.99% 可用性），即便节点掉线、某个可用区不可用或你在做升级。
从“始终在线”开始，把它翻译成可衡量的期望：每月最大停机时间、恢复时间目标（RTO）和恢复点目标（RPO）。
分布式 SQL 系统可以在许多常见故障下继续提供读写，但前提是你的拓扑必须匹配你的 SLO，并且你的应用能干净地处理瞬态错误（重试、幂等）。
计划内维护也很重要。滚动升级和实例替换在数据库能把 leader/副本从受影响节点迁移开而不使整个集群离线时更简单。
多可用区 部署保护你免受单个 AZ/可用区故障和多数硬件故障，通常延迟和成本更低。如果你的合规和用户主要集中在单一区域，这通常就足够了。
多区域 部署能保护你免受整个区域故障并支持区域级故障切换。权衡是：若要在多区域间保持强一致性写入，写延迟会更高，且容量规划更复杂。
不要假设故障切换是瞬时且无感的。明确定义“故障切换”对你的服务意味着什么：是短暂的错误激增？只读期？几秒钟的延迟？
运行“演练（game days）”以验证：
即使是同步复制，也要保留备份并排练恢复。备份保护你免受操作错误（错误迁移、误删）、应用错误和可被复制的损坏。
验证是否支持时间点恢复（PITR）、恢复速度，以及在不触碰生产环境的情况下恢复到干净环境的能力。
当法规、合同或内部策略要求某些记录必须存储（有时还要在特定国家/区域处理）时，就会出现数据驻留要求。
这可能适用于个人数据、医疗信息、支付数据、政府工作负载或客户合同规定的数据集。
分布式 SQL 常在此被考虑，因为它可以在保持单一逻辑数据库的同时将数据物理放置在不同区域——而无需为每个地理位置运行完全独立的应用栈。
如果监管或客户要求“数据留在区域内”，仅有低延迟的副本是不够的。你可能必须保证：
这会推动团队把位置作为一等公民，而不是事后考虑的附加项。
SaaS 中常见的模式是按租户（客户）放置数据。例如：欧盟客户的行或分区固定在 EU 区域，美国客户在 US 区域。
通常结合：
目标是避免通过运维访问、备份恢复或跨区域复制意外违反驻留规则。
驻留与合规义务因国家、行业和合同而异，并且会随时间变化。
把数据库拓扑视为合规计划的一部分，并与合格的法律顾问（以及相关审计人员）验证假设。
为驻留设计的拓扑可能会让“全局视图”变复杂。如果客户数据被刻意保留在不同区域，分析与报表可能需要：
实践中，许多团队将操作型工作负载（强一致、驻留敏感）与分析型工作负载分离（区域范围的数据仓库或受控的聚合数据集），以便在不拖慢日常产品报表的前提下满足合规要求。
分布式 SQL 能为你避免痛苦的故障与区域限制，但它通常不会默认节省开支。前期规划能帮助你避免为不必要的“保险”付费。
大多数预算分为四类：
分布式 SQL 系统会增加协调成本——尤其是需要多数副本确认的强一致写入。
一个实用的估算方法：
这并不意味着“别做”，而是说明应设计减少顺序写入的旅程（批处理、幂等重试、减少交互式事务）。
如果用户主要集中在一个区域，单区域 Postgres 加上只读副本、良好的备份和经过测试的故障切换计划，通常更便宜且更简单——并且性能更好。
当你确实需要多区域写入、严格的 RPO/RTO 或驻留感知的放置时，分布式 SQL 才能证明其花费是值得的。
把花费视为权衡：
如果避免的损失（停机 + 流失 + 合规风险）大于持续附加成本，多区域设计就是合理的。否则，从更简单的方案开始——并保留今后演进的路径。
采用分布式 SQL 更多是证明你的具体工作负载在数据与共识分布到节点（及可能的区域）时能良好运作，而不是简单的“搬箱子”。一个轻量的计划能帮助你避免惊讶。
选择一个能代表真实痛点的工作负载，例如：结账/预订、账号开通或账本过账。
提前定义成功指标：
如果想在 PoC 阶段更快推进，构建小型“真实”应用界面（API + UI）通常比仅做合成基准更有帮助。例如，团队有时使用 Koder.ai 快速搭建一个轻量的 React + Go + PostgreSQL 基线应用，然后把数据库层换成 CockroachDB/YugabyteDB（或连接到 Spanner），以端到端测试事务模式、重试与故障行为。关键不是起始栈，而是把“想法”到“可测量工作负载”的循环缩短。
监控和运行手册与 SQL 的重要性不相上下：
从 PoC 冲刺开始，然后为生产准备评审和渐进式切换（尽可能使用双写或影子读）。
如果需要帮助估算成本或层级，请参见 /pricing。要获取更多实践性的演练和迁移模式，可浏览 /blog。
如果你最终记录了 PoC 结果、架构权衡或迁移经验，考虑与团队分享（并在可能时公开分享）：像 Koder.ai 这样的平台甚至提供通过创建教学内容或推荐其他构建者来赚取学分的方式，这能在评估选型时抵消实验成本。
分布式 SQL 数据库提供关系型、SQL 接口（表、连接、约束、事务），但以集群形式运行在多台机器上——常常跨多个区域——并表现为“一个逻辑数据库”。
在实践中，它试图结合：
单节点或主/从复制的 RDBMS 对于单区域 OLTP通常更简单、更便宜且更快。
当下列情况存在时，分布式 SQL 变得有吸引力：
大多数系统依赖两个核心思想：
这使得即使节点出现故障也能保证强一致性——但它会增加网络协调开销。
它们将表切分为更小的块（通常称为分区/分片，或厂商特定的名称如 ranges/tablets/splits）。每个分区：
通常可通过策略影响放置，从而使“热点”数据和主写入靠近，减少跨网路的往返。
分布式事务通常会触及多个分区，可能位于不同节点（或不同区域）。一个安全的提交可能需要：
这些额外的网络往返是写延迟增加的主要原因——跨区域共识时尤甚。
当下列任意两项或更多为真时，考虑分布式 SQL：
如果工作负载能在一个区域里通过副本/缓存满足，常规 RDBMS 通常是更合适的默认选择。
强一致性意味着一旦事务提交，后续读取不会看到旧数据。
在产品层面，它能帮你避免：
代价是当网络分区发生时，强一致性系统可能会阻塞或失败某些操作，而不是接受短暂分歧的结果。
依靠数据库约束 + 事务：
idempotency_key（幂等键）(account_id, idempotency_key)这样，重试会变成无害的幂等操作，而不是重复项——这对支付、资源配置和后台任务重试尤为关键。
一个实用的划分：
在选择前，测试你实际使用的 ORM、迁移及任何 Postgres 扩展——不要假设能直接替换。
从一个关键工作流（结账、预订、账本记账）开始的聚焦 PoC。验证：
如果需要帮助估算成本/层级，请参见 /pricing。实施说明可参见 /blog。