分布式数据库选型一旦进入高可用方案的深水区，本质上是在选择一种“故障的消费模式”。TiDB 和 CockroachDB 都宣称实现了金融级的高可用，但它们的实现路径和最终能承受的故障类型截然不同。TiDB 的高可用建立在“存算分离 + 多数派共识”之上，核心思路是让故障恢复变得极快且对业务透明；CockroachDB 则走的是“对等节点 + 数据冗余”路线，追求的是在任何极端情况下数据都不丢失，哪怕牺牲一点恢复时间。选型的关键不是看谁的技术更炫，而是看你的业务到底是怕“断”还是怕“丢”，以及你的运维团队能驾驭哪种复杂度。

架构基因决定高可用上限

TiDB 的存算分离架构直接决定了它的高可用特性。计算层 TiDB Server 完全无状态，挂掉任何一台都不影响数据完整性，业务只需重新连接即可。存储层 TiKV 使用 Raft 协议，数据被切分成多个 Region，每个 Region 默认三副本分布在不同的物理节点上。当某个 TiKV 节点宕机时，Leader 选举在秒级完成，期间该 Region 所在的少量数据暂时不可用，但整个集群不会瘫痪。CockroachDB 则采用对等节点设计，每个节点同时承担 SQL 解析和数据存储功能，数据同样通过 Raft 协议复制。区别在于 CockroachDB 的 Range 副本管理更激进，默认将数据分散到所有节点，故障时影响面更均匀，但跨节点协调开销也更大。这两种架构没有绝对优劣，但决定了后续所有高可用策略的基调。

故障恢复机制：速度与完整性的博弈

TiDB 在故障恢复上追求“快”。当 TiKV 节点宕机，PD（Placement Driver）调度器会立即感知并开始补副本，同时触发 Leader 选举。由于 TiDB 的 Region 通常较小（默认 96MB），Leader 迁移速度极快，通常 2-5 秒内完成。但这里有个关键细节：如果宕机节点上的副本恰好是某个 Region 的唯一副本（比如三副本中两个都挂了），这个 Region 会进入不可用状态，直到副本数恢复。TiDB 的策略是优先保证多数派可用，极端情况下宁可短时不可用也不牺牲一致性。CockroachDB 则更强调“存活”，它的 Raft 实现允许通过“非投票副本”和“预投票”机制在多数派丢失时尝试恢复，甚至在某些场景下可以手动干预强制恢复集群。代价是恢复流程更复杂，时间可能拉长到分钟级。如果你的业务是电商交易，几秒的不可用可能造成资损，TiDB 的快速恢复更合适；如果是全球分布的元数据管理，CockroachDB 的极端容灾能力更有价值。

多数据中心部署的真实差距

这是两者拉开差距最大的地方。TiDB 的多数据中心方案依赖 PD 的调度策略和 Label 标签系统。你可以给 TiKV 节点打上“zone”、“region”、“host”等标签，PD 根据这些标签确保同一个 Region 的副本不会落在同一个故障域。例如配置“3 数据中心 5 副本”时，可以做到每个数据中心至少有一个副本，且 Leader 集中在主数据中心以降低延迟。但 TiDB 的跨数据中心写入仍然受限于 Raft 多数派提交，如果主数据中心和其他数据中心之间有网络延迟，写入性能会线性下降。CockroachDB 原生支持多区域部署，它的“生存目标”和“延迟目标”配置允许你精细控制数据放置。比如可以设置某个表的数据“在 AZ 故障时保持可用，但跨洲延迟不超过 100ms”，CockroachDB 会自动选择最合适的副本分布和 Leader 位置。更关键的是，CockroachDB 支持“跟随者读取”，可以从就近的副本读取稍旧的数据，这对全球化部署的读多写少场景是杀手锏。TiDB 的 Follower Read 功能虽然也支持从副本读取，但需要显式开启且对事务一致性有严格限制。

备份恢复与数据保护的最后防线

高可用的最后一道防线是备份恢复。TiDB 在这方面工具链更成熟，BR（Backup & Restore）工具支持全量备份、增量备份和日志备份，恢复速度极快，1TB 数据通常 10 分钟内就能恢复。配合 PiTR（Point-in-Time Recovery）可以实现任意时间点恢复，这对金融合规至关重要。CockroachDB 的备份恢复则深度集成在 SQL 层，通过 BACKUP 和 RESTORE 语句操作，同样支持增量备份和时间点恢复。但 CockroachDB 的备份文件格式与云存储深度绑定，恢复时需要重新分布数据到节点，大集群恢复速度不如 TiDB 的 BR 工具。另外，CockroachDB 的“保护性恢复”机制允许在误删数据时通过“AS OF SYSTEM TIME”语法查询历史数据，相当于内置了一个时间旅行功能，这是 TiDB 目前需要借助 Flashback 功能才能实现，且限制更多的能力。

运维复杂度：被低估的选型因素

高可用方案最终要靠运维落地。TiDB 的组件多（TiDB Server、PD、TiKV、TiFlash），监控体系庞大，但好在 TiUP 工具和 Grafana 模板非常成熟，扩容缩容基本自动化。故障处理时，运维人员需要明确区分是计算层还是存储层问题，操作路径清晰。CockroachDB 的单体架构运维起来更像传统数据库，一个二进制文件搞定所有，但这也意味着故障定位更难，一个节点的 CPU 飙高可能同时影响 SQL 执行和 Raft 心跳。CockroachDB 的 Web UI 提供了丰富的集群状态信息，但日志系统不如 TiDB 结合 Prometheus + Grafana 那么灵活。如果你的团队已经有 TiDB 运维经验，迁移成本低；如果是从零开始，CockroachDB 的入门门槛更低，但深入调优更难。

实际选型决策框架

选 TiDB 还是 CockroachDB，建议按以下维度打分：第一，数据一致性要求是否达到“绝对不允许丢数据”？如果是，CockroachDB 的极端容灾设计更保险。第二，故障恢复时间目标（RTO）是否要求在 5 秒以内？TiDB 的快速 Leader 选举和 Region 调度更适合。第三，是否有多区域、跨洲的读写分离需求？CockroachDB 的跟随者读取和多区域配置更原生。第四，团队是否具备精细化管理分布式系统的能力？TiDB 的组件拆分虽然复杂，但出问题时更容易隔离；CockroachDB 的简单架构背后是更高的诊断门槛。第五，是否需要强依赖的生态工具？TiDB 的 TiCDC 数据同步、TiFlash 分析引擎等生态更丰富。最后，不要被“分布式”概念绑架，如果你的数据量在 TB 级以下、并发不过万，单机数据库加主从复制可能比两者都更“高可用”。

配置示例：TiDB 跨机房高可用拓扑

以下是一个典型的 TiDB 三机房部署配置片段，展示如何通过 Label 实现副本的跨机房分布：

# tikv.toml 配置片段
[server]
labels = { zone = "zone1", host = "host1" }

# pd.toml 配置片段
[replication]
location-labels = ["zone", "host"]
max-replicas = 5

# 使用 pd-ctl 配置隔离级别
config set isolation-level zone

这段配置确保 PD 在调度副本时，同一个 zone 内不会放置超过两个副本，从而在单机房故障时仍保证多数派存活。CockroachDB 的对应配置则更简洁，通过 SQL 直接设置区域属性：

ALTER DATABASE mydb PRIMARY REGION "us-east1";
ALTER DATABASE mydb ADD REGION "us-west1";
ALTER DATABASE mydb ADD REGION "eu-west1";
ALTER DATABASE mydb SURVIVE REGION FAILURE;

这种声明式配置降低了人为出错的可能，但灵活性也受限于 CockroachDB 内置的调度算法。

长期维护的隐性成本

高可用不是一次性配置，而是持续运营的状态。TiDB 的版本升级通常需要滚动重启各个组件，过程中可能短暂影响性能但不会中断服务。CockroachDB 的在线升级更平滑，节点逐个替换时集群自动重平衡。但 CockroachDB 的“重平衡”本身会消耗大量网络和 IO 资源，如果集群规模大且数据量大，升级窗口期可能被拉得很长。TiDB 的 PD 调度器可以通过参数限制平衡速度，避免影响在线业务。另外，两者在扩容时的表现也不同：TiDB 扩容 TiKV 节点后，PD 会自动迁移部分 Region 到新节点，迁移速度可控；CockroachDB 扩容后数据重分布更激进，可能导致性能抖动。这些日常运维细节往往比理论上的高可用指标更能决定最终体验。