城市级故障自动无损容灾的“新常态”方案
背景
2017年7月，OceanBase高可用部署有了一个新的里程碑：支付宝的会员ID系统采用OceanBase“三地五中心”部署方式，建立了城市级故障自动容灾能力。这是第一个完全依赖数据库内部机制建立的城市级故障自动容灾系统，并且应用在金融领域的核心业务上，具有重要的标志性的意义。
会员ID系统为支付宝提供基础的会员登录、限权、身份识别基础服务，是支付宝的重要基础设施之一。用户登录、鉴权及用户信息管理等操作都强依赖该服务，因此对高可用和性能都有很高的要求，一方面要具备城市级故障容灾的能力，另一方面对读操作的延迟也有很高的要求。
传统方案
在传统的解决方案中，通常会采用“两地三中心”来解决城市级故障的容灾问题，采用读写分离的方案来解决读操作的性能问题。顾名思义，“两地三中心”通常指的是在两个城市的三个机房内各部署一套独立的数据库系统，同城两机房间数据进行同步复制，数据强一致；异地机房间采用异步复制的方式，数据有一定的延迟。主库提供数据库读写服务，备库可根据业务需要提供读服务。主流商业数据库通常有成熟的同步工具，对同步过程中的异常也有较完善的处理，“两地三中心”是一个普遍采用的方案。
对于开源系统来说，异地容灾依赖的外部组件成熟度有待提升，整体方案比较复杂，由于在关键核心领域的应用较少，可维护性和可靠性都存在一定的问题。在原先的实践中，架构如下图一所示，主要碰到如下几类问题，对业务产生了不好的影响：
不支持表模式变更自动同步，DDL操作需要到读库和写库分别进行；
同步软件容错性不好，出现异常需要人工参与重启恢复；
同步软件性能存在瓶颈，导致备库和主库之间的数据延迟较大；
同步初始配置复杂，主备库之间的数据一致性校验成本高；
自适应能力不足，在主库发生机房级的切换后，需要重新配置备库的源；
图1传统读写分离部署
“三地五中心”方案
OceanBase的“三地五中心”方案在数据库系统层面解决上述的两个问题：城市级故障容灾及读扩展能力。与传统方案相比，该方案具备如下特点：
在单个城市故障的情况下，不丢失任何数据；
读操作性能不下降；写操作延迟根据城市之间的距离有所增加；
主库自动故障切换，读库自主寻找合适的源进行数据同步；无需人工参与，运维简单；
整个方案对上层业务透明，应用无需为此做任何改动；
不依赖第三方同步平台和工具，完全基于数据库自身的多副本机制；
支付宝会员ID系统“三地五中心”的整体架构如图2所示，可以看出，整个数据库集群由5个支持完整读写操作的read/write zone（R/W Zone1 ~ R/W Zone5）和4个只支持读操作的read only zone（RO Zone6 ~ RO Zone9）组成，这9个zone分布在三个不同的城市，其中城市1有一个数据中心、城市2、3各有两个数据中心。
上层业务系统对读、写操作进行了区分，写操作的流量只会分发到城市1、2，由app_write_1~3发起，至少要在两个城市之间进行日志同步，根据城市之间的距离及网络情况，延迟在几毫秒到几十毫秒；三个城市都支持在本地读取数据，由app_read_1~6发起，读操作会根据一定的策略选取同一个城市的某一个数据副本，通常优先选择本zone的只读副本，同时不会跨城市（Region）读取数据。
在一个城市发生故障的时候，数据库集群仍然能够对外正常提供读、写服务。假如城市1发生故障，5个read/write zone的超过半数（3或者4）仍然能够形成多数派，写操作仍然可以成功，响应时间根据城市之间的距离远近有所增加；除故障城市外，另外两个城市的读操作没有任何影响，仍然会在本地读取数据。
当两个或者两个以上城市出现故障的时候，由于超过一半的read/write zone无法正常工作，写操作不能成功，但是未发生故障城市的读操作仍然是正常的。当然，两个或者更多城市同时发生故障的概率几乎为零。
图2 OceanBase “三地五中心”部署
只读Zone机制
为支持“三地五中心”及读写分离的部署方式，OceanBase新增了read onlyzone机制。和通常的read write zone不同的是，read only zone中分区的副本都是只读副本，即该副本只参与和全功能（read/write）副本之间的日志同步，但不参与paxos协议的投票。增加read only zone可以有效扩展整个集群对外提供的读能力，同时不会增加写操作的响应时间。通过在相应的城市和地区增加read only zone，本地的业务系统可以就近读取数据，一方面缩短了读操作的响应时间，同时也增大了系统的吞吐率，可以线性扩展整个集群的读能力。在成本上，相对于原先的单独部署一套多副本的读库来说，有了大幅度的降低。
带有read onlyzone的“三地五中心”部署方式，大大降低了系统运维的复杂度。对DBA来说，只需要部署一套OceanBase集群并且根据需要创建几个zone（read/write或者read only），就既可以解决城市级故障容灾的问题、又能够扩展读操作的能力。十分方便，是不是？
后续
由于上述的优势， OceanBase“三地五中心”部署方式（带readonly zone），将逐步推广到对高可用和性能要求都很高的金融核心业务场景，成为金融核心业务数据库集群部署的新常态。