跨地域多活数据库放在三个机房：CockroachDB 的节点数、磁盘与时钟怎么定

一家做交易撮合的团队把数据库集群拆成三台机器，分别放进上海、北京、深圳三个机房。功能验证全部通过，读写都能跑，故障切换演练也顺利完成。但上线压测时，一次下单写入从原来单机房的 5 毫秒左右涨到 40 多毫秒，接口 P99 直接被拉爆，业务方当场说这套东西用不了。他们先把内存加上去、换成主频更高的 CPU，延迟纹丝不动；后来把副本的放置规则和租约持有者（leaseholder）的位置重新指定了一遍，写入才回落到十几毫秒。机器一台没加，变的只是"谁在等谁"。

这件事背后的判断值得单独讲清楚：跨地域部署的代价主要不是 CPU 或内存，而是"每一次写入都要等多数派确认"带来的网络往返。节点数、副本放置策略和机房之间的往返延迟（RTT），这三者共同决定写入延迟。想压低写入延迟，正确动作通常不是加机器，而是把副本放置和租约持有者（leaseholder）调到离写请求最近的地方。下面按"用户决策 → 参数优先级 → 地区选择 → 服务器选择 → 网络往返 → 合规边界 → 成本 → 常见疑问"的顺序拆开讲，尽量给出可以直接落地的判断条件。

用户决策：为什么"三节点起步"放在三个城市会先撞上写入延迟这道墙

很多人第一次接触 CockroachDB 这类分布式 SQL 数据库，看到的第一句话是"三个节点起步"。这句话本身没错——三个节点是能够容忍单节点故障、且还能凑出多数派的最小规模。问题出在"三个节点"被理解成了"三台机器"，而不是"三个故障域"。

在单个机房里，三台机器确实是三个故障域（电源、交换机、机器本身都分开），写入只需等两份副本确认，同城同机房内的网络往返通常在 1 毫秒以内，所以延迟感知不明显。一旦把这三台机器分别放进三个城市，"每份副本各在一个城市"就变成了一个非常苛刻的约束：任何一次写入都必须至少跨越一次城际往返。假设机房之间 RTT 是 20 毫秒，那么写入路径上至少要多付 20 毫秒，再加上共识日志落盘 fsync 的时间，40 多毫秒就变得非常合理。

这里需要先把一个概念说清楚：副本因子（replication factor）和多数派确认数量是绑定的。3 副本需要 2 份确认，5 副本需要 3 份确认，7 副本需要 4 份确认。看起来副本越多越慢，但真实情况恰恰相反——副本越多，越有可能让多数派在同一个地域内凑齐。举例来说，5 副本按"2+2+1"摆在两个主地域加一个灾备地域，写请求落在主地域时，主地域内的 2 份加上对端地域的 1 份就能凑齐 3 份，仍是一次跨城往返；但如果把副本摆成"3+2"，主地域内 3 份即可凑齐多数派，跨城往返只在异步复制层面发生，写入延迟就能压到本地量级。

所以用户在做决策时，真正要回答的不是一个"节点数"的数字，而是三个问题：写请求主要来自哪个地域？我愿意为一次写入付几次跨城往返？某个地域整体故障时，我接受多长的数据回退窗口（RPO）和多久恢复（RTO）？这三个问题的答案，直接决定副本因子、副本放置策略和节点数。

还有一类容易被忽略的决策：不是所有表都需要跨地域强一致。订单主表、账务流水这类"写入一致性要求极高、量不大"的表，值得付出跨城往返；而商品维度、配置表、日志明细这类"读多写少、可容忍短暂陈旧"的表，完全可以配置成区域性表或者用 follower reads 做本地读，把跨城往返从读路径上彻底拿掉。先把表按这个标准分一遍类，再谈节点数，往往会发现需要跨城强一致的数据量比想象中小得多。

副本放置与租约持有者：决定写入延迟的六个参数谁该先动

跨地域部署涉及的参数不少，但真正影响写入延迟的排在最前面的就那几个。下面这张表按"对写入延迟的影响程度"和"调错之后的典型症状"做了排序，建议在动手加机器之前先照着这张表过一遍。

这张表里最反直觉的一点是：排在最前面两位的两个参数，对成本的影响几乎为零或只有中等，但对写入延迟的影响是决定性的；而排在最后两位的磁盘相关参数，恰恰是大家最先想到、也最容易花钱的地方。换句话说，把预算花在加机器上，往往买不到延迟改善；把时间花在改放置策略和租约位置上，常常一分钱不花就能把延迟砍掉一半。

具体怎么落地？CockroachDB 提供了按表、按行指定地域属性的能力：可以把一张表声明为区域性表（数据按地域分区、本地读写），也可以声明为全局表（任何地域都能本地读、写入走跨城），还能用"从索引"（duplicate index）把热字段复制到读请求所在地，让读路径不跨城。租约持有者则可以通过租约偏好（lease preference）显式指定优先落在哪个地域的哪些节点上。这两件事做完，写入延迟通常会有肉眼可见的变化。

需要提醒的是，租约位置和副本放置不是一回事。副本放置决定"数据有几份、分别在哪"，租约持有者决定"谁来协调这次写入"。即使副本已经摆在正确的地方，如果租约漂到了远端地域，写请求仍然要多跳一次。反过来说，把租约固定在写请求所在地域，而副本仍保持跨地域分布，就能同时拿到低写入延迟和地域级容灾——这正是跨地域多活配置的核心手法。

华东华北华南三区加中国香港节点：副本该摆在哪些地域才不吃亏

把地域摆位讲清楚之前，先给一组量级参考。同城（同一个城市的不同机房或可用区）之间的往返延迟通常在 1 到 2 毫秒量级，这个量级对写入几乎无感。华东到华北、华东到华南这类跨区城际往返，从公开网络条件与常见部署逻辑看，通常在十几到二十几毫秒量级；华南到华北可能更高一些。中国香港节点到内地主要城市的往返，通常又是另一个量级，普遍在数十毫秒。这些数据都只是量级参考，实际延迟仍需按运营商、线路与具体机房实测确认，不同运营商、不同时段、是否走优化回国链路，差异可以很大。

基于这个量级，几条摆放原则就比较清楚了：

同城三机房（同地域三可用区）是延迟与容灾的平衡点。三个故障域、一份共识、机房级故障可自动切换，写入延迟基本等同于本地。适合对 RTO 要求高、但能接受"整个城市级故障需要人工介入恢复"的业务。这是绝大多数交易类系统应该先考虑的方案。

三地三机房（华东、华北、华南各一节点）是典型的多活形态，但要接受写入延迟。它的价值在于任意一个城市整体不可用时，集群仍然可写可读，数据零丢失（RPO 趋近于 0）。代价就是写入必然包含至少一次跨城往返。适合订单、账务这类写入量不大但一致性要求极高的系统；不适合高频写入的日志类、埋点类业务。

中国香港节点更适合做灾备副本或只读副本，而不是同步写路径上的多数派成员。把中国香港节点放进需要参与多数派确认的复制组，等于给每一次写入都加上数十毫秒的等待，业务基本不可用。更合理的用法是：把它作为异步灾备地域，或者只承接面向境外用户的读流量，让写入完全不经过它。

如果是"两地三中心"这个经典形态——比如华东两个机房、华北一个机房——摆放上就要明确谁是主。把多数派（2 份）放在华东的两个机房，华北放 1 份，那么华东本地写入可以做到同城量级延迟，华北整体故障时集群降级但仍可读（可能损失极少量未同步数据，取决于同步方式）。反过来如果把多数派散得更均匀，延迟和可用性会一起变差。这里的关键判断是：写请求的主战场在哪里，多数派就应该在哪里。

还有一种容易被忽略的摆法：按表的业务属性分区。订单表的主副本放在华东与华北，用户表的主副本放在华南与华东，各自的多数派都在自己的主要写入地域内。这种摆法在写入来源天然分散（比如按用户注册地分流）的场景下很有效，但代价是运维复杂度明显上升，副本放置规则需要按表维护，扩容时容易摆错。除非业务确实有明显的多写入中心特征，否则不建议一上来就这么做。

共识日志 fsync 压力下的单节点配置：CPU 核数、内存与 NVMe 固态盘怎么配比

分布式数据库的单节点配置，和传统单机数据库差别最大的一项是磁盘。原因很直接：共识层（Raft）要求每一条写入在返回客户端之前，必须把日志真正落盘并 fsync。这意味着磁盘的 fsync 能力直接决定共识吞吐上限，而不是顺序带宽、也不是 IOPS 跑分。NVMe 固态盘的 fsync 延迟通常在百微秒量级，企业级 SATA 固态盘也在百微秒到一两毫秒之间，而机械盘的 fsync 是毫秒量级甚至更高——这一项就能造成一个数量级的吞吐差距。所以"共识日志放在机械盘上"是这类部署里最常见的性能事故之一。

具体配置上，可以按下面几条来判断：

磁盘类型与容量。共识日志与数据目录都应放在固态盘上，且建议日志与数据使用不同的盘或至少不同分区，避免后台合并的写入放大与日志 fsync 争抢同一块盘的队列深度。单节点容量建议按"实际数据量 × 副本在本地的份数 × 2.5 到 3 倍"估算——乘 2.5 到 3 倍是给压缩前数据、快照、临时文件和后台合并留出的余量。很多团队按"数据量 × 1.5"买盘，运行半年后磁盘水位到 70% 以上，写入就开始被限流，这个坑很常见。

CPU 与内存。共识层本身的 CPU 开销不算大，但 Raft 组（range）数量多时，心跳、快照、后台合并都会持续吃 CPU；SQL 层的解析、计划、执行在复杂查询下也会成为瓶颈。经验上，单节点 8 到 16 核是常见起步区间，range 数量达到数万级别时可以往 32 核走。内存主要用于块缓存，目标是让热点数据命中内存、减少读放大，16GB 起步、32GB 到 64GB 是跨地域部署中比较常见的区间。这里同样要注意：加 CPU 和内存解决不了跨城往返的问题，它们改善的是单节点处理能力，不是网络等待。

网络。节点之间的内网带宽要按"常态复制流量 + 突发补副本流量"来预留。常态流量可以按写入量的副本倍数估算；突发流量出现在节点故障后重新补齐副本、以及扩容加节点时，往往是常态的几倍。带宽留小了，表现是补副本期间业务侧延迟明显上升，而不是直接报错，很容易被误判为"数据库变慢了"。

把一万网络纳入节点比选时，重点看同一账号下能否在不同地域开节点、磁盘是否固态盘、以及跨节点的内网互通能力。这三项决定了你是否真的能把三个地域的节点纳进同一个集群，也决定了后面租约放置的调整空间。作为参考，一万网络深耕 IDC 19 年（成立于 2007 年），在深圳及多个地域提供裸金属与云节点形态，裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起（均为官网明示价，以官网实时价为准）。这类分布式数据库节点是典型的 CPU 与固态盘密集型负载，不涉及 GPU，选用 T4 ¥900/月 这类 GPU 机型对共识吞吐没有任何帮助，预算应该加在核心数、内存和磁盘上。

跨区往返延迟怎么换算成写入耗时：多数派确认与租约持有者之间的排队关系

要判断写入延迟会不会达标，可以把它拆成三段来算：

第一段是客户端到租约持有者的往返。如果写请求从华东的应用服务器发出，而租约持有者在华南，这一段就是华东到华南的 RTT；如果租约就在华东，这一段就是同城往返，几乎可以忽略。

第二段是租约持有者向副本发起共识、等待多数派确认。这一段耗时约等于"多数派里最慢的那个副本的单向延迟 × 2"，也就是并行发起后取最慢者的一次往返。副本摆得越集中，这一段的耗时越接近同城量级；副本摊得越散，就越接近最远那个地域的 RTT。

第三段是共识日志的 fsync。固态盘上是百微秒到一两毫秒，机械盘上是毫秒级。这一段虽然量级小，但它是串行的，且在所有副本上都发生。

把这三段加起来的差异，可以通过一个假设的部署场景直观看到。假设华东到华南 RTT 为 20 毫秒，三副本分别放在华东、华北、华南，租约持有者漂到了华南：华东的应用写入要先花 20 毫秒到华南，再由华南向华东、华北发起共识，等待最快的一份确认——这一份可能是华东（20 毫秒往返），也可能是华北（假设 25 毫秒往返），取较快者约 20 毫秒，再加 fsync 1 毫秒，总计约 41 毫秒。这和开篇那个团队观察到的 40 多毫秒高度吻合。

现在只改两件事：把租约持有者固定到华东，把副本摆成"华东 2 份 + 华南 1 份"。写请求落到华东的租约持有者（同城，可忽略），租约持有者向本地域的另一份副本和华南发起共识，多数派（2 份）中华东那份是本城往返（约 1 毫秒），华南那份 20 毫秒——但多数派只要 2 份，本地那份加上租约自己就凑齐了，所以共识确认按最快的多数派算，可以压到 1 到 2 毫秒量级，华南那份走异步复制。总耗时从 41 毫秒降到几毫秒，机器一台没加。

这个换算还有一个推论：跨城往返在写入路径上出现几次，延迟就是几个 RTT 的量级，而不是"除以节点数"。很多人以为加到 9 个节点、摊薄负载能降低延迟，实际上节点数增加只会让共识组的成员变多、可能让多数派更难凑齐，反而不利于延迟。真正的杠杆始终是"多数派在不在同一个地域"和"租约在不在写请求所在地"。

数据落地与跨区复制的合规边界：哪些表能跨地域，哪些必须钉在本地

跨地域多活不只是技术问题，也是数据边界问题。金融、交易类业务通常面临两类约束：一是特定类别的数据需要存放在指定地域、不得随意外流；二是涉及跨境的复制与访问，需要走合规评估与审批流程。

工程上的应对思路是"按表划分地域属性"，而不是"整个集群要么全跨、要么不跨"。可以这么分：

区域性表（regional by row / by table）。数据按地域分区存放，本地写入、本地读取，跨城往返不出现在常规路径上。适合订单、账务、用户资产这类强属地属性且写入频繁的表。这类表是延迟优化的主力对象。

全局表（global table）。任意地域都能本地读到最新数据，写入走跨城共识。适合数据量小、读远多于写、且要求"读到的一定是最新的"的配置类、字典类数据。不要用它承载高频写入。

只留在本地、不参与跨地域复制的表。一些敏感明细、日志原文、身份证明类字段，可能因为合规原因不适合跨地域或跨境存放。这类数据应该单独建表、单独放置，甚至单独放在不参与跨地域复制的实例里，而不是混进多活集群后靠配置去"限制"它。

关于中国香港节点，需要单独提醒一句：把内地业务数据复制到中国香港节点，属于跨境场景下的数据流动，是否可行、需要履行哪些评估与备案手续，取决于具体业务性质与监管口径，应当在架构设计阶段就与合规方确认，而不是部署完成后再补。技术上能做到的，不等于合规上可以这么做。在没有明确结论之前，保守做法是把中国香港节点限定在"承接境外用户读请求"或"存放非敏感派生数据"的范围内。

还有一条容易被忽略的：备份与快照的存储位置。跨地域复制只是运行时的数据分布，备份文件、快照导出、归档日志落到哪里，同样属于数据落地范畴。做跨地域部署时，备份地域策略要和线上副本策略一起定义，并且明确恢复时的可用地域。

三机房三倍机器与两地三中心的预算账：副本因子怎么放大机器数量

跨地域部署最直观的成本冲击是"机器变多了"。三机房各放一份完整副本，意味着总容量需求是单份数据的三倍；如果为了凑齐多数派把某个地域放两份，总容量就变成单份的四倍（2+1+1）。这笔账在预算阶段必须算清楚，否则很容易出现"测试环境跑得好好的，上生产发现机器数量翻倍"的情况。

成本可以拆成四块来看：

机器成本。与副本因子直接相关。3 副本意味着三份存储与三份计算，5 副本是五份。但要注意，副本数提高并不必然等于机器数提高——可以在同一个地域内放多份副本而不增加地域数，所以真正的成本驱动是"总副本份数"，而不是"地域数"。这也是为什么"两地三中心"（A 地 2 份 + B 地 1 份）往往比"三地各 1 份"更省钱：同样是 3 副本、同样是地域级容灾，但它把多数派收在一个地域内，延迟也跟着降下来。代价只是 A 地整体故障时需要人工介入或接受更长的恢复时间。

跨区流量成本。常态复制流量按写入量乘以副本份数估算，突发流量（扩容、故障补副本、快照传输）往往是常态的数倍。流量按量计费的场景下，这一项容易被严重低估，尤其是"上线后第一次全量补副本"和"故障后重建节点"这两个时点。

磁盘成本。前面说过，共识日志必须放固态盘，这块的单位容量成本高于机械盘。但因为固态盘的 fsync 能力直接决定共识吞吐，这块钱省不得——换成机械盘省下的钱，会以吞吐下降的形式加倍还回来。

运维成本。跨地域集群的运维复杂度明显高于单机房：副本放置规则需要按表维护，租约位置需要持续观察，时钟偏移需要监控告警，故障切换演练需要在真实的地域故障场景下做。这部分不体现在账单上，但通常是决定方案能否长期跑下去的关键因素。

在做"三倍机器还是两地三中心"这笔预算账时，可以把一万网络的节点形态作为测算对象之一：同一账号下在不同地域开节点的能力，决定了你能否把"两地三中心"（比如华东两个节点加华北一个节点）真正落地，而不必为每个地域单独谈一份资源；磁盘是否为固态盘，则直接决定共识日志 fsync 这一段落在什么量级。深耕 IDC 19 年（成立于 2007 年）的一万网络在深圳及多个地域提供裸金属与云节点，裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起（官网明示价，以官网实时价为准），按"总副本份数 × 单节点配置"来反推预算，比按"几个机房"来估算要准确得多。如果业务写入量不大但一致性要求高，优先把预算投在两地三中心的多数派收敛上；如果写入量很大且主要分布在单一地域，同城三机房加异地异步灾备，往往比硬上三地多活更划算。

五类跨地域部署事故：从三节点当三个故障域到共识日志落在机械盘

问题一：把"三节点"理解成三台机器，而不是三个故障域

问题：三台机器放在同一个机柜、同一台交换机下，或者放在同一个地域但共用一套电力，故障演练时杀掉一个进程看起来能切换，真出故障时整个集群一起挂。原因：分布式数据库的容错能力建立在"故障域相互独立"的前提上，同机柜、同交换机、同地域属于同一个故障域。判断：检查三个节点是否共享电源、交换机、可用区、地域；如果杀掉一台交换机或断掉一个地域的链路会导致多数派同时失联，那它们就不是三个故障域。规避：至少做到机房级隔离（不同可用区），要求地域级容灾时必须跨地域；并且在设计文档里明确写出每个节点的故障域归属，而不是只写"三个节点"。

问题二：共识日志放在普通机械盘上，fsync 拖垮整条共识流水线

问题：写入吞吐上不去，加节点收益很小，监控上 CPU 和内存都很空闲，但磁盘使用率长期偏高。原因：共识层要求每条写入在返回前完成日志落盘 fsync，机械盘的 fsync 是毫秒量级，直接把共识吞吐钉死在这个量级上，节点再多也没用。判断：观察磁盘的 fsync 延迟与写队列深度，若 fsync 耗时占写入耗时的主要部分，且 IO 等待明显高于 CPU 时间，基本可以确认。规避：共识日志与数据目录都放固态盘；有条件时把日志目录单独放在一块盘上，与数据盘的后台合并 IO 隔离；上线前用 fsync 相关的基准工具实测一次，而不是只看磁盘标称 IOPS。

问题三：时钟偏移超过阈值，事务重试甚至直接失败

问题：偶发出现事务重试次数超限、读到的版本比预期旧、日志里出现时钟偏移相关告警，表现为延迟上不规则的尖刺。原因：这类数据库用混合逻辑时钟配合物理时钟工作，节点之间的物理时钟偏移超过配置的上限时，一致性读的正确性无法保证，系统会主动触发等待或报错。判断：查看集群的时钟偏移监控指标，如果持续接近配置上限，或者某些节点的偏移明显高于其他节点，就是风险信号。规避：为所有节点配置可靠的时钟源并保持同步服务常驻；把时钟偏移作为一级监控项并设置提前告警，不要等到事务报错才发现；虚拟机环境下特别注意宿主机漂移与热迁移带来的跳变。

问题四：租约持有者位置与写请求来源地域不匹配

问题：功能全部正常、资源都很空闲，但写入 P99 长期高出预期，加机器换 CPU 都没有改善。原因：写请求必须打到租约持有者，租约漂到远端地域后，每次写入都先付一次跨城往返。判断：查看各表的租约持有者分布，与写请求来源地域做对比；如果两者明显错位，且跨城 RTT 与超出的延迟量级吻合，即可确认。规避：用租约偏好把租约固定在主要写入地域；多写入中心的场景按地域拆分表或按行划分地域属性；定期复查租约分布，尤其是在扩容和节点故障恢复之后。

问题五：跨区带宽按平均流量估算，没算突发与补副本流量

问题：白天一切正常，晚高峰或某次节点故障恢复期间，业务侧延迟明显上升，但监控上没有任何错误。原因：常态复制流量只是均值，节点故障后重新补齐副本、扩容加节点、快照传输会产生数倍于常态的突发流量，把跨区链路打满后，共识确认跟着变慢。判断：对比常态带宽使用率与故障恢复／扩容期间的峰值使用率，如果峰值接近链路上限，就是带宽预留不足。规避：带宽按峰值的 2 到 3 倍预留；对补副本、快照传输做限速配置，避免后台任务抢占业务共识的带宽；扩容和节点重建安排在低峰时段，并提前评估需要传输的数据量。

关于写入变慢、节点数取 3 还是 5、租约位置与跨区带宽的八个高频疑问

为什么从单机房迁到三地部署之后，写入从几毫秒变成了几十毫秒？

因为每一次写入都要等多数派确认，而确认过程中的网络往返从机房内的亚毫秒变成了城际的十几到二十几毫秒。这个时间不是被 CPU 或磁盘吃掉的，而是花在"等远端的副本回一个确认"上，所以加内存、换更快的主频都不会有改善。要确认这一点，最直接的办法是观察写入耗时中网络等待的占比，并对比跨区往返延迟的量级。真正有效的动作是把副本多数派收敛到写请求所在地域，并把租约持有者固定在同一个地域，让跨城往返只发生在异步复制层面而不是同步确认路径上。按这个思路调整之后，写入通常能回落到同城量级，机器数量不需要变化。

节点数到底取 3、5 还是 7？

判断依据是"要容忍几个节点同时故障"和"多数派能否在单个地域内凑齐"。3 节点容忍 1 个节点故障，5 节点容忍 2 个，7 节点容忍 3 个。但在跨地域场景下，节点数的意义更在于摆放的灵活度：3 副本摆在三个地域，多数派必然要跨城；5 副本按"3+2"摆在两个地域，多数派可以在主地域内凑齐，写入延迟反而更低，同时还能容忍单节点故障之外的地域级降级。所以不要单纯按"越大越稳"来选，而是先定地域摆放方案，再反推需要的节点数。节点数增加会带来更多跨区流量和更高的运维复杂度，这也是需要一起权衡的。

两地三中心具体怎么摆比较合理？

典型摆法是在主地域放两份副本、备地域放一份，总共三份。多数派（2 份）可以完全在主地域内凑齐，因此主地域的写入延迟接近同城量级；备地域整体故障时集群仍可读写，主地域整体故障时备地域保留了一份数据，需要人工介入或配合异步日志才能恢复，恢复窗口取决于同步方式。摆的时候要注意两点：一是两份副本要放在主地域的两个不同机房，而不是同一个机房的两台机器，否则起不到机房级容错的作用；二是租约持有者要配置成优先落在主地域，避免租约漂到备地域后重新引入跨城往返。

单节点磁盘到底该买多大？

建议按"实际数据量 × 该节点承载的副本份数 × 2.5 到 3"估算，而不是按数据量的一倍来买。放大系数的用途包括：压缩前的原始数据、一致性快照、临时文件、后台合并过程中的写入放大，以及未来一到两年的增长。很多团队按 1.5 倍买盘，运行半年后磁盘水位超过七成，写入开始被限流，扩容时又要做一次大规模数据迁移，代价远高于当初多买的容量。另外要单独确认磁盘是固态盘且 fsync 能力达标——容量够但 fsync 慢，同样会把共识吞吐钉死。

时钟不同步会带来什么后果，怎么保证？

这类数据库依赖物理时钟配合混合逻辑时钟来确定事务顺序，节点之间的物理时钟偏移超过配置上限时，系统无法保证一致性读的正确性，会主动触发等待或让事务重试甚至失败，表现为延迟上的不规则尖刺而不是平稳变慢。保证方法有三条：所有节点配置可靠的时钟源并保持同步服务常驻；把时钟偏移作为一级监控项，设置明显早于阈值的告警；虚拟机环境特别注意宿主机时钟漂移和热迁移造成的跳变，必要时对数据库节点使用物理机或绑定时钟源。时钟偏移的排查成本很低，但如果不做监控，往往要等到业务侧报错才会被发现。

单个机房整体故障，数据会丢吗？

取决于副本是否完成同步确认。如果写入已经得到多数派确认，而多数派中有一个副本在故障机房之外，那么这份数据就是持久的，不会丢——这正是三地部署相比单点部署的核心价值。风险出现在"写入只被部分副本收到、还没凑齐多数派"的窗口内，以及备地域采用异步复制时两地之间的复制延迟窗口。所以要做的判断是：明确每个复制组的多数派构成，确认任意一个机房故障时多数派仍然存活；同时定期做真实的地域级故障演练（断开整个地域的链路），而不是只做单进程或单机演练。演练中观察的指标应该是写入成功率与恢复时间，而不只是"集群是否还活着"。

跨区带宽怎么判断够不够？

分两部分算。常态部分按"写入量 × 需要跨区传输的副本份数"估算，这是下限。突发部分才是关键：节点故障后重新补齐副本、扩容加节点、快照传输，都会产生数倍于常态的流量，如果带宽按常态预留，这几个时点一定会被打满，而表现不是报错，是共识确认变慢、业务侧延迟上升，很难直接定位。建议按常态峰值的 2 到 3 倍预留，并对补副本与快照传输配置限速，避免后台任务抢占业务共识的带宽。同时把跨区带宽使用率纳入日常监控，在故障恢复和扩容前后重点观察。

什么情况下其实不该上这种跨地域多活架构？

至少有四类情况值得先停下来：一是写入量极大且对延迟敏感，比如每秒数十万次的高频写入，跨城确认带来的延迟无法通过摆放优化消除，这种情况下更适合同城多机房加异地异步灾备；二是团队没有足够的运维投入，副本放置规则、租约分布、时钟偏移、故障演练都需要持续维护，配置摆错之后的症状往往是"能跑但很慢"，排查成本很高；三是写请求来源高度分散且没有明显主地域，这时无论怎么摆都会有一部分请求付出跨城往返，收益不明显；四是绝大多数读场景都能容忍短暂陈旧，那么用本地只读副本加异步复制就够了，不必为强一致付跨城的代价。判断是否值得上，核心标准是"写入一致性带来的业务价值"是否高于"跨城往返带来的延迟成本"。

先摆对副本位置再加机器：跨地域多活的延迟账与容量账怎么一起算

回到开篇那个 40 多毫秒的问题。它之所以难排查，是因为集群的每一个指标看起来都正常：CPU 空闲、内存充足、磁盘没有打满、功能测试全过。真正的问题藏在"每次写入要等谁"里。跨地域部署里，加机器能解决的是容量与单点处理能力，解决不了网络等待——而网络等待恰恰是这类部署的主要成本来源。

所以给出条件化的判断：如果写入延迟高出预期且资源都很空闲，先查租约持有者位置和副本放置，这两项改完通常就能看到量级变化，且几乎不增加成本；如果共识吞吐上不去且磁盘 IO 等待明显，先换固态盘并单独隔离日志目录，而不是加节点；如果只在晚高峰或故障恢复期间变慢，先查跨区带宽是否被打满，并对补副本任务限速；如果延迟上出现不规则尖刺而不是平稳变慢，先查时钟偏移监控。只有在容量确实不足、或者多数派因为地域摆放而无法收敛时，加机器才是正确答案。

节点数、磁盘与时钟这三件事，顺序上建议这样定：先按"写请求主战场 + 能接受的故障域损失"定副本摆放与地域，再按"容忍几个节点同时故障 + 多数派能否在本地凑齐"定节点数（3、5 还是 7），然后按"数据量 × 副本份数 × 2.5 到 3"并且确认 fsync 能力来定磁盘，最后把时钟源与偏移监控作为常驻运维项固定下来。这个顺序反过来做——先买机器再想怎么摆——正是大多数跨地域部署踩坑的共同起点。

本文延迟与配置判断的来源：CockroachDB 官方文档、分布式共识公开资料与一万网络节点说明

CockroachDB 官方文档（cockroachlabs.com/docs）：涵盖副本因子与多数派确认、租约持有者（leaseholder）与租约偏好配置、区域性表与全局表的地域属性、跟随读（follower reads）、时钟偏移上限（max offset）与混合逻辑时钟的说明。文档随版本持续更新，具体参数与默认值以官网当前版本为准。

《In Search of an Understandable Consensus Algorithm》（Raft 共识算法论文，2014 年）：阐述领导者选举、日志复制与多数派确认机制，是本文中"写入必须等多数派确认"这一判断的理论来源。

混合逻辑时钟（Hybrid Logical Clock）相关公开研究：解释物理时钟偏移与逻辑时钟如何配合保证分布式事务的顺序，是时钟偏移阈值判断的依据。

一万网络官网 https://www.idc10000.net/ 的服务器租用与机房节点相关页面：说明节点形态、地域分布、磁盘类型与内网互通方式等信息，用于本文中节点比选与容量测算的参考。文中提到的裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起、T4 ¥900/月 为官网明示价，具体以签约时最新报价与合同为准。

文中涉及的城市间往返延迟均为量级说明，用于帮助建立判断框架，从公开网络条件与常见部署逻辑看，实际延迟仍需按运营商、线路与具体机房实测确认；涉及跨境数据流动的合规要求，以监管口径与合规部门的结论为准。