容灾系统是核心业务必不可少的可用性保障措施，然而每年全球依然有众多大型机构因为数据中心级别故障导致核心业务终止，造成数百亿的经济损失。血淋淋的教训比比皆是，但数据中心级别事故依然“乐此不彼”，其中关键因素之一就是传统的容灾方案架构设计复杂、实施困难、可靠性低，往往投入大量资金，却换不来关键时刻的有效安全保障。

容灾系统是为了应对火灾、地震等极端地域性灾难事件而设计的跨数据中心安全保障手段。RPO和RTO是两个衡量容灾能力的指标，单位都是时间。RPO代表容灾系统最大数据丢失量；例如RPO=1分钟，则代表生产系统发生故障后，业务切换到容灾系统，可能会丢失最近1分钟内变更的数据。RTO代表业务从故障状态恢复到可正常运行状态所需的时间。银行业是对容灾要求最严苛的行业，根据《商业银行数据中心监管指引》要求，总资产规模超过一千亿的商业银行和省农信等，应该设立异地模式灾备中心，且要求至少达到RTO小于2天、RPO小于30分钟的容灾水平；实际上在大型银行机构中都要求核心系统容灾能够满足同城RPO=0、RTO分钟级的能力。

一、传统容灾方案设计复杂、实现困难、可靠性低

数据库作为业务数据存储与计算支撑的基础软件，也是保障容灾系统RPO和RTO指标的最有效技术。传统单机数据库实现容灾方案采用基于日志同步的主从复制技术。将两个或多个独立的数据库分别部署在不同的数据中心，其中一个作为主数据库对外提供服务。传统的IOE架构从软件、硬件、网络等多方面历经数十年形成了一体化的容灾解决方案，而国产集中式数据库则因为起步时间晚、国产芯片服务器等单品稳定性不足而难以支撑可靠性容灾。

分库分表架构的数据库通过增加数据冗余来降低对服务器设备稳定性的依赖，允许部分服务器设备故障后，业务依然连续、数据不丢失，增强了系统的可用性；但在容灾方案中需要在生产中心和容灾中心服务器之间进行一对一（或者一对多）的日志同步，以此实现跨中心的容灾能力。

图-分库分表架构的容灾部署架构

分库分表架构下每一个节点都是一个独立的单机实例（例如MySQL实例），而基于单机实例的一对多日志同步可靠性本身就很低，当集群规模较大时，就会产生几十个生产实例向上百个备份/容灾实例同步的情况，运维管理成本极大提升；并且这样的架构中除了用户数据同步，还可能涉及到管理节点元数据、全局事务数据的同步，在如此复杂的架构中，只要任一个实例、任一个角色的同步发生异常，那么将会导致整个容灾系统不可用。所以在传统容灾方案中，虽然投入了大量的人力、物力、财力建设容灾系统，但在需要它时，往往发现它却不可用。

二、QianBase无中心对等架构、灵活容灾、简易管理

如果说分库分表架构是分布式1.0时代，那么以Google Spanner/F1为代表的新一代数据库则将数据库带入了分布式2.0时代。分布式2.0是一种全新的数据库架构，也称为原生分布式架构，底层存储不使用单机数据库，而是采用一套完整的分布式存储引擎。数据仍然以分片为单位存储，但是数据的冗余实现并不是采用单机数据库的日志复制，而是基于业界流行的多数派一致性协议实现。每个数据分片都有多个副本，这些副本中有一个Leader副本负责外部的读写操作，其余均为Follower副本被动接收Leader同步过来的日志流。由于Leader副本可以分布于任意数据节点，结合数据库自身的负载均衡能力，每个节点都可以处理外部的读写请求，从而实现了去中心化的服务能力。

易鲸捷公司自研的QianBase xTP数据库是一款典型的原生分布式架构产品，数据以分片为单位采用Raft一致性协议实现多副本复制。QianBase对分片副本的放置管理策略十分灵活，支持将分片副本配置为跨机器、跨机架、跨数据中心、跨地域来进行部署。副本多样化的分布和放置策略使得QianBase数据库集群具有不同的容错能力：

• 将副本分布在相同数据中心相同机架的节点上，可以确保低复制延迟，同时能容忍磁盘或机器故障；

• 将副本分布在相同数据中心的不同机架的节点上，可以容忍像机架间网络交换机故障；

• 将副本跨越不同数据中心进行分布，可以容忍灾难性故障如区域电力故障、火灾、地震等。

可以看出，QianBase只需要部署一套集群，就可以轻松的实现跨中心容灾的场景，相比分库分表架构，大大减化了整体架构以及运维成本。

图-QianBase通过多副本实现主备数据中心容灾

上图所示主中心和灾备中心均有3个副本，按照多数派提交原则，当过半副本（即4个）同步成功后事务提交成功。由于主中心只有3个副本，意味着灾备中心至少有1个副本是强同步的，因而这种部署模式可以满足RPO=0。当整个主中心不可用时，通过修改一定的配置后，异地中心的3个副本组成一个新的组并重新使用多数派提交。

图-QianBase主中心故障后切换到灾备中心

基于多数派一致性协议的数据同步本质上是强同步复制，主要适用于同城容灾场景，而对于距离较远的异地容灾，传统的一致性协议并不能很好的支撑。QianBase以一致性算法为基础，创新性的实现了Oracle的三种容灾模式，完美的支持了异地容灾、两地三中心等容灾场景。

图-XX银行基于QianBase两地三中心容灾方案

以银行两地三中心容灾部署为例，在配置生产中心为“主中心”后，其他的数据中心可以在以下三种容灾模式中灵活选择：

• 最大保护模式。和主中心事务强一致，时刻保证RPO=0。

• 最大性能模式。此中心只是异步的同步主中心数据，不要求和主中心事务强一致，RPO可能大于0。

• 最大可用模式。当本中心系统健康时和主中心数据强一致，保证RPO=0，此时效果与“最大保护模式”一致；当本中心系统异常时，则自动降级为“最大性能模式”进行异步复制主中心数据；在异常修复后，自动恢复为RPO=0。

除了三种容灾模式的实现，QianBase以Raft理论和算法为基础，还进行了多项的技术突破，包括实现了主机房内选主算法、主备机房联合提交算法、主备机房切换算法、机房级数据恢复拓扑重构算法等；丰富了心跳协议，防止因代理、队列引起的滞后心跳状态识别错误；实现类似流处理快照技术，实现计算多组Raft的事务一致checkpoint等。QianBase基于全栈国产化的两地三中心容灾方案和同城两中心容灾方案都已经在银行核心系统中实战检验，证明QianBase是一款能够支撑金融级跨中心容灾方案的分布式OLTP数据库。