- 背景
OceanBase 1.0底层通过Paxos协议在保证强一致性的前提下实现了高可用。Paxos是一种强同步协议，理论上无法规避网络延时问题。因此，在设计容灾方案时，需要考虑机房架构、网络架构对部署的影响。
另外，传统数据库采用主备模式只需要两个副本，而OceanBase使用Paxos协议，至少需要三个副本，甚至五个副本，相应地，OceanBase也需要避免大量副本占用过多资源。 - 容灾能力
本文主要考虑RPO为0，RTO在1分钟以内的自动无损容灾，并将容灾能力划分为三个等级：
服务器（Server）级无损容灾：能够容忍单台服务器不可用，自动无损切换；
机房（Zone）级无损容灾：能够容忍单个机房不可用，自动无损切换；
地区（Region）级无损容灾：能够容忍某个城市整体不可用，自动无损切换。 - 异地三机房
理想的容灾方案是地区级容灾。以GoogleSpanner系统为例，全球部署一套生产系统，每次写入都会通过Paxos协议跨地区同步到多个城市。这种方式的问题在于写入延时太长，Google Spanner系统每次写入延时在几十毫秒到几百毫秒之间，取决于不同副本所在城市之间的物理距离。
如果采用异地三机房部署，每次数据库事务提交都会增加一次异地同步延时。一般来讲，国内不同地区之间的机房延时（例如上海到深圳）在几十毫秒左右，而每一笔业务往往包含多个数据库事务。因此，可能需要对业务进行针对性改造，减少每一笔业务包含的数据库事务个数。 - 同城三机房
折衷的方式是只支持机房级容灾。通过Paxos协议的原理可以知道，为了支持机房级容灾，至少需要有三个机房；否则，当一个机房出现故障时，另外一个机房无法单独构成多数派，也就无法实现无损切换。
三个机房中，一个机房为主库，另外两个机房为备库。APP和主库部署在同一个机房，如图1所示。
图片
图1 同城三机房
正常情况下，APP访问部署在同机房的主分区，即APP访问机房1的A1、B1、C1。当机房1的OceanBase出现故障时，它上面服务的主分区可能切到机房2或者机房3，例如A1、B1、C1分别切到A2、B3、C2。接下来，部署在机房1的APP会跨机房访问新的主分区A2、B3、C2。等到机房1从故障中恢复过来以后，OceanBase又会把主分区重新切回机房1的A1、B1、C1，避免APP跨机房访问。在这种情况下，机房1是OceanBase的优先机房，内部通过primary zone来标识。当然，如果机房1整体故障，里面的APP往往也不可用，应用系统有一套针对APP的容灾方案。APP容灾不是我们的讨论重点，本文的讨论均假设APP是持续可用的。
对于同城三机房部署，每次事务提交都需要至少强同步到另外一个机房的某个备副本。蚂蚁的同城网络延时在2ms毫秒，因此，每次事务提交增加的延时小于2毫秒，而蚂蚁核心业务一次数据库事务往往包含6~15条SQL语句，整个事务的执行时间在15毫秒到50毫秒左右，2毫秒的额外延时可以接受。 - 两地三中心
考虑到机房和网络建设成本，部分地区可能总共只有两个机房。软件架构应该尽可能普适，因此，我们需要对这种场景做专门的设计。
由于机房级无损容灾至少需要三个机房，因此，除了同一个城市的两个机房外，还需要在另外一个城市找第三个机房，一起组成两地三数据中心。
5.1. 2 + 2 + 1部署
图片
图2 “2 + 2 + 1”部署
如图2，假设深圳有两个机房，上海一个机房。对于每个分区，深圳机房分别部署两个副本，上海机房只部署一个副本，形成“2 + 2 + 1”部署。每个分区总共包含五个副本，正常情况下，只需要强同步深圳的三个副本即可，每次事务提交增加的网络延时在1.9毫秒之内。
当上海机房出现故障时，仍然只需要强同步深圳的三个副本，系统无影响。当深圳机房出现故障时，例如深圳2机房故障，此时，系统总共只有三个副本。如果不做处理，每个事务提交时都需要做一次深圳到上海的跨地区同步，网络延时不可接受。OceanBase的做法是利用Paxos协议做一次成员变更操作，将深圳2机房的副本从Paxos选举组中剔除，副本总数由五个变成三个。这样，以后只需要同步三个副本中的两个即可，避免了跨地区同步。为什么可以这样做？这是因为成员变更也是Paxos协议的一部分，只要同时得到变更前与变更后的多数派承认，成员变更即可生效。
5.2. 对比关系数据库“两地三中心”
传统关系数据库在银行往往也部署成“两地三中心”，同城两个机房，一个主库，一个热备；异地一个冷备。当主库出现故障时，无论热备还是冷备，都没有包含最新的修改，因此，除非等待主库恢复才提供服务，否则，强制将备库切为主库必然导致数据丢失。
这就意味着，传统关系数据库的“两地三中心”方案要么选择高可用，要么选择强一致。如果选择高可用，RTO可以做到很小，但是RPO总是大于0；如果选择强一致，RPO等于0，但是RTO不可控。而OceanBase的“2 + 2 + 1”方案虽然也部署了两地三中心，但是，底层通过Paxos协议实现了机房级无损容灾。当某个机房出现故障时，RPO为0且RTO在1分钟以内。 - 双机房热备
部分业务可能总共只有两个机场，这种情况下，理论上无法做到机房级无损容灾。此时，OceanBase提供双机房热备容灾方案。
图片
图3 双机房热备
如图3，主机房和备机房分别独立部署了OceanBase 1.0集群，主机房的集群称为主集群，备机房的集群称为备集群。主集群的三个分区A1、B1、C1是主分区，备集群的三个分区A4、B4、C4是主分区。主集群的修改操作会异步复制到备集群。如果单台OceanBase服务器故障，能够自动无损切换，RTO在1分钟以内，RPO为0；如果主集群整体故障，可以将备集群强制切换为主集群继续提供服务，RTO在5分钟以内，RPO在秒级。这就意味着，双机房热备方案支持服务器级无损容灾，不支持机房级无损容灾。 - 交叉部署
在图1中，OceanBase部署了三个机房，机房1为主机房，机房2和机房3为备机房，无法提供服务，相当浪费。可以做成交叉部署，如图4所示，A1、B2、C3为主分区，分别部署在机房1、机房2和机房3，从而把这三个机房的OceanBase机器资源都给用上，避免浪费。
图片
图4 三机房交叉部署 - 小结
本文介绍了OceanBase1.0在不同场景下的容灾方案。通过底层的Paxos协议，当出现节点故障时，OceanBase能够在多数派可用的前提下实现无损切换。
在实际的生产系统中，OceanBase会根据机房的分布情况选择合适的部署方案，从而权衡可用性与每次事务提交的延时。OceanBase支持同城三机房部署，也支持“2 + 2 + 1”两地三中心部署，还支持双机房热备容灾。其中，“2 + 2 + 1”部署是OceanBase的独特创新，与传统数据库相比，OceanBase使用同样甚至更低的成本实现了机房级无损容灾。
最后，OceanBase也支持交叉部署。通过这些方式，OceanBase的容灾方案基本不会增加额外的成本，系统内部也只有强一致性一个选项，避免了在强一致与高可用之间做各种复杂的折衷。
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
