OceanBase常用的高可用及容灾方案
OceanBase 数据库从诞生之初，就利用Paxos协议在底层实现了多副本数据一致性，具有上述“RPO=0、低RTO（通常在30s以下）、故障时自动切换”的优势。而经过多年实际应用场景的历练后，尤其是像支付宝、淘宝、网商银行这种高并发、高访问量、24*7持续交易场景的磨练，OceanBase数据库已经摸索出一套完整的、经过实践检验的高可用及容灾方案。下面我们就结合OceanBase数据库的实践经验，向大家介绍一下分布式数据常用的一些高可用及容灾方案。
特别说明一下，在后文的示意图中会有一些经常用到的名词，在此先做个简单的说明，以方便大家理解：
- OBServer
一个OBServer指的是一个独立提供服务（share-nothing）的OceanBase数据库节点，这是一个软件层面的定义。但通常一台物理服务器上只有一个OBServer，因此也可以认为一个OBServer等同于OceanBase数据库集群的一个物理节点。
- Zone
这是OceanBase数据库的一个内部概念。一个Zone是一个或者一些OBServer组成的逻辑集合，一个Zone里的所有OBServer都在一个机房内。
从分布式多副本数据一致性协议的角度来看，可以认为一个Zone就是OceanBase数据库集群的一个“副本”，如果是三副本架构那就会有三个Zone。
- IDC
IDC就是大家通常理解的“机房”的概念，一个IDC就代表一个机房。
1.1 单机房3副本
这是最简单的一种方案，在一个机房内找足够多的机器，把它们划分成3个Zone，每个Zone里一份副本。
这种方案具备一定程度的高可用能力，可抵御个别硬件故障，比如在个别服务器宕机、个别硬盘损坏等情况下，数据库集群还能持续提供服务。此外，这种方案具有部署方便，成本低的特点，只要有一个机房，机房内有足够多的联网机器，就可以部署了。
但这种方案也有一个非常明显的劣势：不具备容灾能力。如果发生机房级灾难或者城市级灾难，首先会导致交易停止，而极端情况下（比如机房所有机器损毁）甚至会导致数据丢失。
综合来看，这种方案虽然部署方便，也具备高可用特性，但其容灾的能力却是最低的，对于具有容灾要求的系统来说显然是不适合的。如果用户的硬件条件有限，只能提供一个机房，并且用户对系统的容灾能力没有要求，那么这种方案是一个非常合适的选择。
1.2 同城3机房3副本
同样是个城市内部署3副本，这种方案相对于“单机房3副本”来说就更进了一步：在同一城市内找3个不同的机房，每个机房内部署1个Zone（1份副本），形成一个跨机房部署的 数据库集群。
由于分布式多副本数据一致性协议要将每一个事务的数据强同步到多数派副本中，这种部署模式下必然导致频繁的跨机房同步操作。为了保证数据库的写性能，对机房之间的网络质量有比较高的要求，通常要求任何两个机房之间的网络时延不超过2毫秒（ms）。（P.S. 后面所有关于“同城机房”的描述中，默认都有类似的网络要求，后文就不再赘述了）
相对于“单机房3副本”来说，这种方案的优势是很明显的：除了可以抵御个别硬件故障，还可以抵御机房级灾难：任何一个机房遇到灾难，都不会导致交易停止或者数据丢失。
不过，并不是每一个用户都能够提供“同城三机房”的部署条件。即使是高端企业级用户，往往也只具备同城2机房（主机房+同城灾备机房）的条件，因此3机房对用户的基础设施来说提出了一定的挑战，也增加了用户的部署成本。如果考虑到上面说的任意2个机房之间都要做到“网络低延时”，那成本会进一步增加。因此，在考虑这种部署方案时，要事先和用户做好充分的沟通，确保用户能提供符合要求的基础设施。最后还要指出的一点就是，这种方案仍然不具备城市级容灾的能力，如果发生城市级灾难，还是会导致交易停止，甚至有数据丢失的风险。
综合来看，如果用户能够提供同城3机房的硬件设施，并且没有城市级容灾的要求，那么推荐使用这种方案，可以在城市内提供非常好的高可用及容灾能力。事实上，OceanBase数据库的一些外部企业级客户就是采用了这种部署方式，收到了很好的效果。
如果用户暂时只具备同城2机房的条件，那么可以考虑在城市内租借一个机房以满足“同城3机房”的条件，其成本相对于建设一个全新IDC来说还是低了很多。甚至可以只为个别数据库集群租借一个同城机房内的部分机柜，这样就进一步降低了成本，对企业级用户来说这个成本应该还是在可接受范围内的。
1.3 3地3机房5副本
前面介绍的几种方案中，提到了机房内高可用能力和机房级容灾能力，但是都无法抵御城市级灾难。下面向大家介绍一种具备城市级容灾能力的方案：3地3机房5副本方案。
这种方案相对来说要复杂一些。首先需要有3个城市，每个城市各有1个机房，利用这3个机房组成一个跨机房部署的OB集群。其次，和前面“同城3机房3副本”的方案类似，这种方案对不同机房间的网络质量是有一定要求的，通常来说需要满足下面的条件：
1）有2个城市的距离相对较近（比如杭州和上海），它们之间的网络时延低于10毫秒（ms）。这2个城市的机房中各部署2个Zone（副本）。
2）第3个城市和前两个城市的距离相对较远（比如深圳），它和前2个城市之间的网络时延应保证在30毫秒（ms）内。这个城市的机房内部署1个Zone（副本）。
在这种部署模式中，距离较近的2个城市有2个IDC，合计4份副本，构成了Paxos协议要求的多数派，因此日常写交易中的强同步操作会集中在这2个城市中，不会涉及到距离较远的第3个城市，有效避免了远距离RPC对交易性能带来的影响。如果2个距离较近的城市中有任何一个Zone发生故障，剩下的3个Zone依旧构成多数派，还是不会涉及到距离较远的第3个城市，性能不会受到影响。如果这2个城市中有1个城市发生了机房级灾难或者城市级灾难，剩下的1个城市和距离较远的第3个城市合在一起还有3个Zone，依旧构成多数派，还是可以继续提供服务，但此时远距离RPC操作将不可避免，性能也会因此而受到影响。因此，这种方案可以全方位抵御个别硬件故障、机房级灾难和城市级灾难，提供最高级别的高可用性，使数据安全性得到了最大程度的保障。
不过，这种方案虽然能够提供全面的数据安全性保护，在实际部署中也会面临一些问题和挑战。首先，需要在3个城市内各有一个机房，3个城市之间要满足“2近1远”，而且相互之间的网络时延也要满足一定条件（详见前文描述），可以说这对用户的基础设施条件提出了非常大的挑战，即使对高端企业级用户来说，也很难满足这个条件，最多只具备2地3机房的条件。另外，5副本相对于3副本来说增加了2个副本，进一步提高了硬件成本，也加大了这个方案的难度。
在实际应用中，如果用户对SLA提出了最高要求，需要抵御机房级灾难和城市级灾难，并且希望做到 “RPO=0、低RTO、故障时自动切换” ，那么此方案将是不二之选。事实上，网商银行的数据库集群部署就是采用这种架构，支付宝中的部分核心数据也是采用了这种架构，它们为业务提供了最佳的数据安全性保障。
对国内的企业级用户来说，在短期内恐怕还很难满足这种方案的基础设施要求。但目前只有3城市的部署架构才能在城市级灾难时做到 “RPO=0、低RTO、故障时自动切换” ，因此从长远考虑可以在基础设施层面提前有所规划。
1.4 同城2机房3副本
前面介绍过，如果只需满足机房级容灾的要求，那么可以考虑 “同城3机房3副本” 的方案，以抵御个别硬件故障和机房级灾难。但由于历史原因，很多企业用户都建设了“同城2机房（主机房+同城灾备机房）”的基础设施，却很少有用户具备“同城3机房”的条件。此时虽然可以租用一个同城机房来满足3机房条件，但如果用户真的找不到合适的第3机房，是否就不能在2机房中部署OceanBase数据库集群了呢？
其实，这种情况下还是可以利用2机房来完成部署的，只要在主机房中部署2个Zone，同城灾备机房中部署1个Zone，就构成了一个跨机房部署的数据库集群。
这种部署模式下，主机房内的2个Zone构成了多数派，因此日常的写交易都会在主机房内部完成数据强同步，可以保证最佳性能。同时，这种方案也可抵抗个别硬件故障，如个别服务器宕机、个别硬盘损坏等情况。
但如果主机房发生机房级灾难，那么整个数据库集群只剩下同城灾备机房的1个Zone，不再满足多数派条件，无法继续提供服务。因此这种方案是不能抵御机房级灾难的，只是在同城灾备机房中保留了一份数据，以后可以将数据恢复出来（但RPO>0，数据会有少量丢失），避免了数据全部丢失的情况。
综合来看，“同城2机房”的条件下，如果拥有多数派副本的机房（通常是主机房）发生灾难，剩下的一个机房无法单独提供服务（这是由分布式多副本数据一致性协议的理论所决定的）。从高可用的角度来看，这种方案不具备机房级容灾的能力，只是避免了数据全部丢失的风险 ，这个结果大大降低了同城灾备机房的实际意义 。
在实际应用中，OceanBase数据库基本不会采用这种方案。相比之下，“同城3机房3副本”方案具备提供机房级容灾的能力，能提供更强的高可用性，是一个更好的选择。考虑到增加第3个机房为用户带来的额外成本，OceanBase数据库还提供了“日志副本”技术：用户可以在已有的2个机房中各部署1个普通副本，在第3个（新增加的）机房中部署1个日志副本。相对于普通副本来说，日志副本可以显著降低存储成本，这样可以在完全不影响RPO的情况下降低第3个机房的拥有成本，减小了用户部署第3个机房的难度。
1.5 2地3机房5副本
前面介绍过，“3地3机房5副本”的方案可以提供最高级别的高可用性，可以抵御个别硬件故障、机房级灾难和城市级灾难等各种情况。但我们同时也提到了，传统企业用户很少能满足“3地3机房”的要求，很多企业用户只具备 “2地3机房（主机房+同城灾备机房+异地灾备机房）”的条件。那么这种情况下，分布式数据库是否能利用“2地3机房”完成部署呢？
事实上，这种情况下OceanBase也可以完成数据库集群的部署，只要在主机房和同城灾备机房中各部署2个Zone，在异地灾备机房中部署1个Zone，就构成了一个跨机房部署的数据库集群。
从架构上看，这种部署方案和“3地3机房5副本”方案有类似之处，可以抵御个别硬件故障和机房级灾难（读者可参照前面“3地3机房5副本”方案的描述做推理，具体过程这里就不详述了）。
但是和“3地3机房5副本”相比，这种方案缺少了城市级容灾的能力：一旦主机房和同城灾备机房所在的城市发生灾难，剩下的异地灾备机房只有1个Zone，不再满足多数派条件，无法继续提供服务，只是在异地灾备机房中保留了一份数据，以后可以将数据恢复出来（但RPO>0，数据会有少量丢失），避免了数据全部丢失的情况。
综合来看，“2地3机房”的条件下，如果拥有主机房和同城灾备机房的城市发生灾难，剩下的一个城市无法单独提供服务。从高可用的角度来看，这种方案不具备城市级容灾的能力，只是避免了数据全部丢失的风险，这个结果大大降低了异地灾备机房的实际意义。
在实际应用中，OceanBase数据库基本不会采用这种方案。相比之下，“3地3机房5副本”方案具备城市级容灾的能力，能提供更强的高可用性，是一个更好的选择。此外，还可以进一步利用前文提到的“日志副本”技术：用户可以在已有的2个城市中各部署2个普通副本，在第3个（新增加的）城市中部署1个日志副本，这样可以在完全不影响RPO的情况下降低第3个城市中机房的拥有成本，减小了用户在第3个城市中部署机房的难度。
最后，如果用户实在无法找到第3个城市来部署机房，但同时可以接受“发生城市级灾难时RPO>0”的代价，那么可以在两个城市之间采取“集群间数据复制”的方法（后文有详细的介绍）。这种方式的弊端很明显，遇到城市级灾难时会有“RPO>0，不能自动切主导致RTO较长”的问题，但它可以利用2个城市实现城市级（有损）容灾，减小了部署的难度。如果采用此方案的话，“主”城市应该采用“同城3机房3副本”的架构，以提供机房级容灾的能力。
1.6 集群间数据复制
这种方案类似传统数据库的“主从复制”方案，通过数据复制软件将一个OceanBase数据库集群的数据复制到另一个（或者多个）OceanBase数据库集群，以应对单个OceanBase数据库集群的故障。通常来说，不同的OceanBase数据库集群会部署在不同的IDC中，以应对机房级灾难和城市级灾难。
这种方式主要是为了应对以下几种情况：
- 只有2个机房的条件下，希望能够具备机房级容灾的能力。
- 只有2个城市有机房的条件下，希望能够具备城市级容灾的能力。
此时，分布式多副本数据一致性协议便无法满足需求，比如前面提到过的：“同城2机房3副本”的方案无法抵御机房级灾难，“2地3机房5副本”的方案无法抵御城市级灾难。而采用传统数据库的“主从复制”模式（准确地说，是它的一个变种），则能满足这类需求。
不过，这种方案的弊端也是很明显的。首先，和传统数据库一样，具有“RPO>0，不能自动切主导致RTO较长”的问题，其次这种部署方式下数据的副本数达到了6个，成本也比较高。
综合来看，这种模式只适用在“用户实在无法满足机房配置要求，但又希望具备机房级容灾和城市级容灾能力”的特殊场景下。我们前面提到过，由于历史原因，不少企业级用户恰恰是有这种需求：希望用同城2机房的部署实现机房级容灾能力，用2地3机房的部署实现城市级容灾能力。因此，如果用户能接受此方案的各种弊端（RPO>0，RTO较长，副本数过多），就可以用这种方案实现高可用及（有损）容灾能力。
总结
通过前面对几种方案的详细阐述，相信大家已经对OceanBase及分布式数据库的高可用和容灾方案有了大致的了解。说来说去，核心思想就是要充分利用分布式多副本数据一致性协议的原理，并结合各种意外情况的具体特点（个别硬件故障？机房级灾难？还是城市级灾难？），找到对应的解决之道。如果客户的基础设施条件有限，不能满足分布式多副本数据一致性协议的部署要求，那么可以考虑引入其它方式，比如集群间数据复制。
下面的表格中，将上面几种方案做了一个总结，方便读者参考：
大体来讲，针对不同的具体情况，下面几种方案都满足了 “RPO=0、低RTO、故障时自动切换” 的要求，而且在技术上没有明显的缺陷，应该作为高可用及容灾方案的首选：
- 单机房3副本方案
如果没有任何机房级容灾或者城市级容灾的要求，只有最简单的高可用要求，那么这种简单易行的部署方案是再好不过了。
- 同城3机房3副本方案
如果有机房级容灾的要求，但没有城市级容灾的要求，那么这种方案是最佳选择。
如果用户只有同城2机房而没有建设第3机房，可以考虑在同城内租借一个机房（甚至只租借部分机柜）来满足3机房的条件，并可以利用OceanBase的“日志副本”技术降低部署难度。
- 3地3机房5副本方案
如果既有机房级容灾的要求，也有城市级容灾的要求，那么这种方案能全部满足，提供最高级别的高可用性。
如果用户的基础设施条件有限，无法满足上面几种方案的要求，但同时又要求机房级容灾能力或者城市级容灾能力，应考虑“集群间数据复制”方案。
最后，也必须意识到技术在不断进步，OceanBase在不断进步，用户的IT建设也在不断进步。今天的最佳方案也许明天就能找到更好的替代者，因此我们必须以发展的眼光持续进化我们的技术方案，才能让OceanBase的用户在未来有更多更好的选择。在这个过程中，我们也非常希望和业界的朋友及广大用户有更多的技术交流和思想碰撞，共同推进分布式数据库技术下高可用及容灾方案的发展， 谢谢！
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群（33254054），或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
