从两地三中心到多地多中心，OceanBase如何实现金融级高可用

“两地三中心”已成为金融领域基准的容灾部署模式。本文将简要阐述金融行业容灾架构中“两地三中心”的具体要求和部署，并进一步探讨OceanBase在实现“两地三中心”标准后，再至“多地多中心”部署中所展现的独特优势与特点。

商业银行的容灾要求

《商业银行数据中心监管指引》中明确规定了商业银行数据中心的要求。

第七条总资产规模一千亿元人民币以上且跨省设立分支机构的法人商业银行，及省级农村信用联合社应设立 异地模式灾备中心 ，重要信息系统灾难恢复能力应达到《信息安全技术信息系统灾难恢复规范》中定义的灾难恢复等级 第5级 （含）以上；其他法人商业银行应设立同城模式灾备中心并实现数据异地备份，重要信息系统灾难恢复能力应达到《信息安全技术信息系统灾难恢复规范》中定义的灾难恢复等级第4级（含）以上。

灾难恢复第5级是个什么意思呢？可以参考这篇文档, 简单地说，灾难恢复级别有一到六，共六个级别，级别越高要求就越高。一到三级不要求热备，只要有定时的冷备即可；四到六级要求有热备，区别如下:

第四级不要求有远程备份，也不要求实时备份。(RPO数小时到一天，RTO数小时到两天)
第五级要求有远程备份和实时备份。(RPO小于30分钟，RTO数分钟到两天)
第六级要求数据零丢失，灾难自动切换(RPO = 0, RTO数分钟)

总结起来就是商业银行数据中心一定要有实时备份和异地热备，否则就不符合要求。

两地三中心

"两地三中心"指的是一种可以满足要求的容灾架构。两地是指同城、异地，三中心是指生产中心、同城容灾中心、异地容灾中心。同城双中心加异地灾备中心即“两地三中心”，这一方案兼具高可用性和灾难备份的能力。

同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。
异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。

同城两中心、异地两中心、两地三中心如下图所示:

从两地三中心的定义来看，实际上阿里和蚂蚁内部的一些业务部署已经实现甚至超过了两地三中心的要求了。

RPO和RTO

两地三中心模式下，有两种灾难恢复。

同城切换：生产中心故障，切换到同城容灾中心。
异地切换：生产中心和同城容灾中心都故障，切换到异地容灾中心。

指引中并不要求同城和异地切换的不丢数据，对RTO的要求其实也是比较宽松的（切换时间小于60分钟）。现有的实际系统也基本没有能做到RPO = 0的。

双活的问题

两地三中心是个比较笼统的概念，并不要求同城的双中心都可以提供读写服务，实际的系统可以分为三类：

同城容灾中心不能提供读写服务
同城容灾中心可以提供读服务
同城容灾中心可以提供读写服务

只有第三类才能叫做"双活", 一种双活的部署示意图图如下：

实现双活，数据要做双向复制，所以通常只能选择逻辑复制，比如Oracle的GoldenGate和Alibaba集团的DRC。

容灾方案的各种权衡

容灾能力和成本的权衡：备份越多，数据就越安全，但同时成本就越高。
强一致和高可用的权衡：如果采用Oracle的最大保护模式，那么当热备不可用的时候，主库也不可写入，可用性降低，无法接受；如果不采用最大保护模式，就无法保证切换时不丢数据，也不完美。这是典型的CAP权衡.
RPO和RTO的权衡：假设备份是异步复制的，当灾难发生时，如果立即切换，可以保证RTO较小，但会丢数据；如果等主库恢复，可以不丢数据，但保证不了RTO，如果主库永远恢复不了，那么RTO就是无穷大了。
异地强同步和事务延迟的矛盾：如果要做到异地切换不丢数据，那么就要把数据强同步到异地，这样事务commit延迟就会变大，业务可能无法接受。如果要做到commit延迟小，那么异地备份就只能是异步的，这也就意味着异地切换一定会有丢数据的风险。

OceanBase如何处理上面的各种选择题的？

容灾能力 vs 成本：不牺牲容灾能力, 想办法降低成本。我们相信有足够的技术手段在不降低容灾能力的前提下有效降成本。
强一致vs 高可用：放弃主备模式，采用Paxos协议，同时达到强一致和实践上的高可用。这个区别对容灾方案来说是根本性的。
RPO vs RTO：因为我们坚持强同步，因此不存在RPO和RTO的权衡。
异地强同步和事务延迟的矛盾：这是唯一一个无法完美解决的矛盾, 最终需要由业务决策。OceanBase即支持远程强同步，也支持远程异步同步。但OceanBase作为一个分布式数据库有潜力能帮助业务更好地解决事务延迟的问题。

总结一下，RPO > 0是一种妥协，长远来看，RPO = 0会变得越来越重要，如果不能保证RPO = 0，数据库系统就把本质的复杂性暴露出去了。就好比ACID这些年逐渐成为分布式数据库的标配(new SQL vs No SQL)，我们可以期待某一天RPO = 0也成为容灾的标配。

OceanBase支持的多地多中心部署方式

OceanBase作为分布式数据库，以Partition为单位管理数据，每个Partition有多个副本，多副本之间使用Paxos协议同步日志，任意时刻，只要多数派的副本正常，这个Partition就可以提供读写服务。

OceanBase支持的最常见的部署方法是两地三中心、三地三中心及三地五中心，这三种方案都要求每个Partition有5个副本。

两地三中心

假设深圳有两个机房，上海一个机房。对于每个分区，深圳机房分别部署两个副本，上海机房只部署一个副本，形成“2 + 2 + 1”部署。每个分区总共包含五个副本。

这种方案的好处是：

正常情况下，只需要强同步深圳的三个副本即可，每次事务提交增加的网络延时在1.9毫秒之内。
任意一个机房故障，不丢数据，并且事务延迟不受影响。当上海机房出现故障时，仍然只需要强同步深圳的三个副本，系统无影响。当深圳机房出现故障时，例如深圳2机房故障，OceanBase的做法是利用Paxos协议做一次成员变更操作，将深圳2机房的副本从Paxos选举组中剔除，副本总数由五个变成三个。这样，以后只需要同步三个副本中的两个即可，避免了跨地区同步。

三地三中心和三地五中心

三地三中心和两地三中心部署是很相似的，不过把三个机房分布在了三个城市，这样任何一个城市故障，都不会丢数据。

三地五中心相比于三地三中心, 需要五个机房，把每个副本部署到不同的机房，进一步强化机房容灾能力。

三地部署，实现了城市级容灾，但牺牲了事务延迟，是否采用三地部署需要业务的权衡。蚂蚁的业务通常要操作多个数据库，数据库的commit延迟到业务层面会被放大很多倍。通常业务需要改造才能容忍commit延迟从1ms放大到几十ms, 业务改造的问题这里不详细讨论，但是OceanBase作为一个容量可扩展的分布式数据库，理论上是可以把蚂蚁的业务要操作的表都放到一个OceanBase数据库里，相比于单机数据库有更多的可能减小网络延迟的影响，

交叉部署

OceanBase以Partition为单位组织数据，不同Partition都是独立管理的，不同Partition的leader可以是不同的。这样的话，我们把不同Partition的leader分布在不同的机房，就可以把写流量分布在不同的机房，避免浪费机房资源。这本质是实现了双活。

传统主备模式用两份机器资源，提供了一份的写能力，OceanBase用三分机器资源，实现了两份的写能力，算起来主备模式的机器利用率只有OceanBase的3/4.

日志副本

一个副本的占用的资源包括：磁盘，内存，CPU。

为了进一步节省机器成本，OceanBase可以选择让一个Partition的5个副本中的部分副本不回放redo log，这样可以省掉CPU和内存资源，甚至不保存静态数据，这样可以省掉磁盘空间。只同步redo log，不保存静态数据，也不回放redo log的副本我们叫日志副本，对应地，正常的副本也叫全量副本。

实际"2 + 2 + 1"部署的时候，可以选择(全 + 日, 全 + 日，全) 这种部署方法。也即前两个机房各有一个全量副本，一个日志副本，最后一个机房只有一个全量副本。

redo log的量相比于静态数据是较少的，所以日志副本占用的资源相比于全量副本是很小的，可以认为OceanBase虽然部署了5副本，但只占用了三副本的资源。