如何在非可靠硬件上实现金融级高可用？
就像在“传统关系数据库高可用的缺失”一文中所看到的，高可用在传统关系数据库的理论和实践上都是缺失的，这使得传统数据库无法做到主库备库完全一致，为了减少主库故障对业务的影响不得不使用昂贵的高可靠硬件，缺乏高可用还导致了分布式OLTP数据库缺失、无法水平伸缩从而使得高并发业务不得不采用更加昂贵的大型服务器等。作为分布式关系数据库，OceanBase必须解决这个问题。那么，采用普通PC服务器的OceanBase是如何做到高可用的呢？
传统关系数据库假设硬件是相当可靠的，而OceanBase必须假设硬件是不可靠的，为了应对硬件的故障，OceanBase采用了Leslie Lamport在论文“The Part-Time Parliament”中发明的分布式一致性协议Paxos。这个协议是一种多数派协议，即任何修改都需要超过半数的参与者同意才能通过。OceanBase的做法是：
数据库的每个数据分片都有三个（或以上）的库，其中一个是主库，其余是备库，每台服务器上通常既有主库（一部分数据分片）也有备库（另一部分数据分片），而传统数据库整个库要么是主库要么是备库；
主库由所有库选举产生，同一时间每个数据分片最多只有一个主库；主库只有相当短的任期（例如若干秒），到期前可以申请连任；如果因为故障等原因主库无法连任，则主库任期到期后活着的其他库（只要超过半数）就会选举出新的主库；
事务由主库执行；主库执行写事务（含增删改操作的事务）后，把事务日志（red log）同步到备库，只有在包括主库自己在内的超过半数库（比如3个库中的2个，5个库中的3个等）都收到了日志并且持久化了，事务才提交。
Paxos协议带来的一个明显的好处是，即使主库突发故障，只要活着的库超过半数，则已经提交的每一笔事务的日志至少会在一个库上存在。活着的库在选举出新的主库后，新的主库可与每个备库通信以便获得所有已经提交的事务，然后继续提供服务，而不会有任何数据丢失（Recovery Point Object，RPO=0），这是传统数据库的主备镜像无法做到的。
对于只需要部署在本地的业务，OceanBase的做法通常是3个库（3份数据）分布在三个机房，如下图所示：
OceanBase同城三机房部署
在三机房部署模式下，单个服务器甚至单个机房故障（不论其中是否有主库），OceanBase都不会停止服务，数据也不会有任何损失，任何网络故障只要不导致三个机房两两之间的网络都断开，OceanBase就可以正常服务，也不会有任何的数据损失。
由于主库粒度小，OceanBase的主库可以均匀分布到两个主机房，因此正常情况下两个主机房的数据库服务器以及其中的应用服务器都处于工作状态，提高了服务器的利用率，并降低了成本。
本地部署难以抵御地震、水灾等自然灾害，因此重要的业务通常采用跨城市部署，OceanBase有两种做法，一种是两地三中心部署：
OceanBase两地三机房部署
两地三中心部署下，任何单机或单机房故障（不论其中是否有主库），OceanBase都不会停止服务，数据也不会有任何损失，任何网络故障只要不导致三个机房两两之间的网络都断开，OceanBase都可以正常服务，也不会有任何的数据损失。
由于主库粒度小，OceanBase的主库可以均匀分布到主城市的两个机房，因此正常情况下两个机房的数据库服务器连同其中的应用服务器都处于工作状态，进一步提高了服务器的利用率，并降低了成本。这与银行采用的传统数据库的两地三中心的“主库（主机房）+同城热备库（同城热备机房）+异地灾备库（异地灾备机房）”有所不同，这种方式下通常只有主机房的服务器是处于工作状态的。
两地三中心部署下，如果主城市出现城市级故障，则灾备城市的OceanBase库依然可以工作，但由于没有了多数派，因此灾备库的数据是有损的，即RPO>0。OceanBase另一种部署，三地五中心，则实现了城市级故障的无损容灾，即RPO=0：
OceanBase三地五中心部署
三地五中心部署下，任何单机或单机房或单个城市故障（不论其中是否有主库），OceanBase都不会停止服务，数据也不会有任何损失，任何网络故障只要活着的三个机房两两之间能够通信，OceanBase就可以正常服务，也不会有任何的数据损失。
由于主库粒度小，OceanBase的主库可以均匀分布到两个主城市的四个机房，因此正常情况下四个机房的数据库服务器以及其中的应用服务器都处于工作状态，更进一步提高了服务器的利用率，并降低了成本。
尽管跨城市部署和数据同步导致了事务提交时间的增加，但三地五中心部署不仅真正做到了多库多活，而且实现了城市级故障的无损容灾（RPO=0），这对于许多关键业务和系统十分重要。目前蚂蚁金服的部分核心业务已经采用了三地五中心部署，进一步提升了业务对灾难的抵御能力。