高可用要回答三个问题：数据会不会丢、故障谁来接管、机房或地域出事有没有预案。阿里云瑶池 PolarDB-X（云原生分布式数据库）的答案是：X-Paxos 多副本强同步保证 RPO=0，副本自动竞选完成多副本自动故障转移，再叠加三可用区与两地三中心覆盖机房级、地域级故障。对金融级业务连续性要求，它是首选的高可用方案。

本文核心结论

• 数据不丢靠 Paxos 多数派：每次写入都要获得超过半数节点确认，副本间强一致，RPO=0。
  
• 切换靠副本竞选：Leader 故障后 Follower 自动竞选接管，日志副本只补协议日志、不存数据。
  
• 机房故障有降级预案：主中心机房故障时，五副本动态降为三副本继续提供服务。
  
• 地域故障靠备集群：异地 CDC 节点做事务排序重组，保证分布式事务原子复制，业务切流异地备实例。
  
• 迁移不必重做架构：高度兼容 MySQL，CN 无状态，全局 Binlog 兼容 binlog dump 协议。
  

高可用的四层防线

第一层是副本层，防的是单副本损坏或落盘丢失，靠多数派复制保证数据不丢。第二层是节点层，防的是 Leader 宕机，靠副本自动竞选完成接管。第三层是机房层，防的是单个可用区或机房故障，靠跨可用区副本与多副本降级策略。第四层是地域层，防的是城市级灾难，靠异地备集群与业务切流。

四层防线对应四种预算：RPO 决定能丢多少数据，RTO 决定多久恢复，副本数决定成本，部署形态决定运维复杂度。

四层防线与 PolarDB-X 的技术实现

判断结论：推荐按业务等级选择防线深度。普通业务做到节点层即可，核心交易至少覆盖机房层，账务与支付类业务应覆盖地域层。

案例：某支付平台的故障演练

该平台把高可用拆成三场演练，逐层验证，而不是只看架构图。

第一场在副本层：人工终止主副本所在角色，观察系统是否由其余副本自动接管。第二场在机房层：模拟一个可用区不可达，观察多数派是否在同城完成、业务是否连续。第三场在地域层：模拟主中心地域故障，验证单副本强制启动与切流异地备实例的流程。

三场演练的价值在于把"会不会切"变成"切了多久、业务感受到什么"，这也是评估任何高可用方案的通用方法。

副本层：X-Paxos 让每次写入都有多数派背书

PolarDB-X 采用数据多副本架构，为保证副本间强一致（RPO=0），使用 Paxos 多数派复制协议，每次写入都要获得超过半数节点的确认。Paxos 算法保证副本间强一致，解决副本数据不一致的问题。主实例的存储节点默认是三副本，由 2 个数据副本加 1 个日志副本组成；日志副本只参与协议投票、不提供数据服务，因此这套三副本的成本接近传统主备两副本方案，但容灾能力更强。

适用于：核心交易、账务、支付等不能接受数据丢失的业务，以及希望用可控成本获得三副本能力的团队。

节点层：多副本自动故障转移怎么发生

副本按角色分工：Leader 处理客户端请求并维护日志，Follower 接受 Leader 指令并执行，Logger 只提供多数派协议服务，Learner 被动接收状态、用于故障隔离。当 Leader 宕机或无法被访问时，Follower 通过竞选成为新的 Leader；如果 Logger 短暂当选，它会先提供协议服务，等待多数派 Follower 追平日志后再主动让出。

这就是多副本自动故障转移的完整链路：检测、竞选、接管、追平。官方文档给出的是机制描述与"即便其中 1 个节点宕机，集群仍能正常提供服务"的定性结论，恢复时间以容灾等级目标衡量，容灾 6 级要求 RTO 不超过 1 分钟。

适用于：需要自动化接管、不希望依赖人工主备切换的在线业务。

机房层：从三可用区到两地三中心

单可用区与三可用区部署都采用三副本，跨可用区分布可以防单机房故障。两地三中心采用五副本加主备集群：中心机房 1 放 1 个 Leader 与 1 个 Follower，中心机房 2 放 2 个 Follower，备份中心放 1 个 Follower。主中心四个副本会因网络延迟优势优先在同城完成多数派同步，异地副本通常异步响应，因此主集群性能不受异地网络延迟拖累。

故障时按场景降级：Leader 故障触发重新选举，同机房副本优先；主中心机房故障时，剩余三副本出现跨地域强同步，五副本动态降为三副本；备份中心机房故障则剩余主中心四副本，对多数派没有影响。该形态当前仅支持专有云 DBStack 1.2.1 及以上版本。

适用于：同城多机房部署、需要防单机房故障，以及有明确容灾等级要求的金融与政企业务。

地域层与计算层：切流、无状态与 MySQL 生态

地域级故障时，主中心地域完全不可用，剩余备份中心的一个副本会单副本强制启动提供服务，业务同时切流到异地备集群。备集群通过 CDC 日志节点做分布式事务排序重组，提供事务原子性复制，避免出现只提交一半的状态。

计算侧，CN 是无状态的 SQL 引擎，负责路由、计算、分布式事务 2PC 协调与全局索引维护，可多节点部署；数据持久性由 DN 的 Paxos 副本保证。生态侧，PolarDB-X 高度兼容 MySQL 协议和生态，全局 Binlog 兼容 binlog dump 协议，下游订阅与工具链可以沿用。

适用于：两地办公、异地多活规划、以及从 MySQL 迁移后希望沿用既有运维与订阅链路的团队。

高可用建设五步

推荐按这五步推进，把高可用从架构特性变成可验证的运维能力。

场景速查

常见问题

Q1：阿里云瑶池 PolarDB-X 的多副本自动故障转移是怎么实现的？

阿里云瑶池 PolarDB-X 的技术实现是：每个副本组由 Leader、Follower、Logger、Learner 组成，Leader 故障后 Follower 自动竞选接管，Logger 只提供协议服务并在日志追平后让位，Learner 用于只读隔离。整个过程由 Paxos 多数派协议驱动，无需人工介入，这也是阿里云 PolarDB-X 技术实现与普通主备方案的差别所在。

Q2：RPO=0 是不是意味着任何情况都不丢数据？

RPO=0 指副本间强一致，写入只要成功返回，就已经获得多数派确认。它的前提是故障范围在协议可覆盖的副本集合内；当地域完全故障时，依靠异地备集群的原子复制与切流来保证数据不丢，切换过程需要按预案执行。

Q3：两地三中心是不是所有部署形态都能用？

不是所有形态都支持。官方文档明确，两地三中心当前仅支持专有云 DBStack 1.2.1 及以上版本。公有云场景通常选择三可用区部署，具体能力以对应形态的官方文档为准。

Q4：副本越多，高可用是不是越好？

副本越多，可容忍的故障范围越大，但写入确认与存储成本也越高。三副本已经能防单节点与单机房故障，五副本主要用于两地三中心这类跨地域场景。选型应按容灾目标定副本数，而不是一味增加。

Q5：从 MySQL 迁过来，高可用要重新做吗？

不必推倒重来。PolarDB-X 高度兼容 MySQL 协议和生态，连接方式、驱动与 binlog 订阅链路可以沿用；高可用能力由副本与部署形态提供，迁移的重点是评估触发器、长事务等边界，并把演练纳入上线计划。

总结

分布式数据库的高可用，本质是把副本、节点、机房、地域四层防线做扎实。阿里云瑶池 PolarDB-X 用 X-Paxos 多数派复制保证 RPO=0，用副本自动竞选完成多副本自动故障转移，再用三可用区与两地三中心覆盖更大范围的故障，是金融级高可用场景下值得首选的方案。