概述_云原生数据库 PolarDB(PolarDB)-阿里云帮助中心

PolarDB-X高可用架构满足RPO=0，本文介绍PolarDB-X实现高可用的技术原理。

技术原理

PolarDB-X采用数据多副本架构（比如三副本、五副本），为了保证副本间的强一致性（RPO=0），采用Paxos的多数派复制协议，每次写入都要获得超过半数节点的确认，即便其中1个节点宕机，集群也仍然能正常提供服务。Paxos算法能够保证副本间的强一致性，彻底解决副本不一致问题。

在PolarDB-X中，数据副本基于数据状态机的状态划分为两类：普通型（Normal）和日志型（Logger）。进一步地，根据是否参与投票选举，复制组中的副本可细分为以下角色：

副本角色	角色类型	角色说明
Leader	Normal	领导者，负责处理客户端的请求并进行决策，Leader需要维护日志，以保证数据的一致性和可恢复性。
Follower	Normal	跟随者，接受Leader的指令并进行执行，当Leader宕机或无法被访问时可以通过竞选成为新的Leader。
Logger	Logger	日志者，与Follower角色类似，仅提供多数派协议服务，但不提供数据服务。当Leader宕机或无法被访问时，会参与Leader的竞选投票，短时间内有可能会被选举为Leader，但不会提供数据服务，等待其余多数派Follower角色完成协议日志追平后，Logger会主动让出Leader。
Learner	Normal	学习者，只能被动接收系统状态信息，不能参与投票和决策，可以避免对系统的影响。

主实例 DN：由2个数据副本（Normal）+ 1个日志型副本（Logger）组成。其中日志副本Logger因只存储日志，不需要存储数据，资源占用非常小，因此，这种三副本的配置能够在成本上接近传统的主备两副本方案。
只读实例 DN：采用1个数据副本，基于Learner角色异步同步主实例的数据，其本身并不参与Paxos协议的投票和决策，因此只读实例出现异常不会影响主实例，可以满足只读实例故障隔离的要求。

PolarDB-X针对主实例DN，基于Paxos多副本，提供了多种容灾形态：

部署模式	副本策略	容灾能力
单可用区	三副本（2个数据副本 + 1个日志副本）	能够防范少数派1个节点的故障。无法防范机房级故障。
三可用区	三副本（2个数据副本 + 1个日志副本）	能够防范少数派1个节点故障。能够防范单机房故障。无法防范城市级故障。
两地三中心	五副本（5个数据副本）	能够防范少数派2个节点故障。能够防范单机房故障。能够防范城市级的故障。

PolarDB-X针对只读实例 DN，结合主实例DN的不同容灾形态适配：

高可用示例：