不同于传统数据库的主备或一主多从方案，OceanBase 同样使用性价比较高、可靠性略低的服务器，但同一数据保存了多台（>=3）台服务器中的半数以上服务器上（例如3台中的2台，5台中的3台等），每一笔写事务也必须到达半数以上服务器才生效，因此当少数服务器故障时不会有任何数据丢失。

不仅如此，传统数据库主备镜像在主库发生故障时，通常需要外部工具或人工把备库升级成主库，而 OceanBase 底层实现了 Paxos 高可用协议，在主库故障后，剩余的服务器会很快自动选举出新的主库，并继续提供服务。在多次蚂蚁机房断网演练中，OceanBase 数据库都做到了自动切换且完全不丢数据，证明了 OceanBase 高可用架构的技术优越性。 OceanBase 提供多种部署模式，可根据对机房配置以及性能和可用性的需求进行灵活选择。

• 同城三机房如果没有异地机房，并且对可靠性要求不是特别的高，采用同城三机房部署方案可以达到机房级容灾。同城机房间的网络延迟一般在0.5ms～2ms之间，所以这种方案具有非常高的性能。更进一步的，甚至可以在同机房的多个机架上部署三个 Zone，能够做到机架级容灾，同时获得更高的性能。

• 两地三中心三副本两地三中心是一类实现高可用和异地容灾的部署模式，这种模式也是监管机构对金融行业数据中心的基本要求。通过在两地的三个中心分别部署一个副本，其中两个副本位于同一个城市，正常情况下事务提交在同城的两个副本完成同步即可，所以具备和同城三机房同样的性能。同时当少数副本所在的城市发生地域级故障时，整个OceanBase 集群的服务不受影响，并且不丢数据。但是当多数副本所在城市发生地域级故障时，会导致OceanBase 停服务。所以相对于同城三机房可用性虽然有大幅的提升，但是本质上这还是一个机房级容灾方案。

• 两地三中心五副本两个城市，一个城市为主城市，另外一个城市为备城市。主城市包含两个机房，每个机房两个副本；备城市只包含一个机房，这个机房只有一个副本。这一方案是两地三中心三副本部署方案的进化，用于解决两地三中心三副本部署方案在多副本所在城市发生机房故障时引入的事务提交跨城市问题。主副本在主城市的数据中心1。如果数据中心2整体故障，那么，Paxos 协议会将数据中心2中的两个副本从成员列表中剔除，成员组由5个副本降级为3个副本，以后只需要强同步3个副本中的2个即可。大部分情况下，强同步操作可以在数据中心1内完成，避免跨城市同步。类似地，如果数据中心1整体故障，那么，Paxos 协议需要首先将主副本切到数据中心2，接着再将成员组由5个副本降级为3个副本，以后强同步操作可以在数据中心2内完成，避免跨城市同步。

另外，为了节省成本，可以分别将数据中心1和数据中心2的各1个副本部署为日志副本。日志副本不提供服务，仅仅接受日志用于故障恢复，从而只需要存储并服务3份数据。

• 三地三中心五副本两地三中心部署方案的问题在于不支持异地容灾。为了支持地区级无损容灾，通过 Paxos 协议的原理可以证明，至少需要3个地区。OceanBase 采用的是两地三中心的变种方案：三地三中心五副本。该方案包含三个城市，每个城市一个机房，前两个城市的机房各有两个副本，第三个城市的机房只有一个副本。和两地三中心的不同点在于，每次执行事务至少需要同步到两个城市，需要业务容忍异地复制的延时。如果仅限于杭州和上海这两个地区之间的强同步，那么，需要容忍大约8毫秒左右延时；如果涉及到长传链路，例如上海和深圳，那么，需要容忍30毫秒左右延时。

• 三地五中心五副本和三地三中心五副本类似，不同点在于，三地五中心会把每个副本部署到不同的机房，进一步强化机房容灾能力。OceanBase 认为未来云数据库的基本要求是完全不丢数据，且底层协议只能选择 Paxos 或者 Paxos 变种。为了支持机房级容灾，至少需要将服务部署到三个机房。虽然这种部署相对主、备双机房部署更加麻烦，但这是必须的。