OceanBase是如何解决城市级故障容灾的

OceanBase是如何解决城市级故障容灾的
背景
2017年7月,OceanBase高可用部署有了一个新的里程碑:
支付宝的会员ID系统采用OceanBase“三地五中心”部署方式,建立了城市级故障自动容灾能力。
这是第一个完全依赖数据库内部机制建立的城市级故障自动容灾系统,并且应用在金融领域的核心业务上,具有重要的标志性的意义。
传统“两地三中心”解决方案
传统的“两地三中心”解决方案,提出了“三地五中心”的新解决方案,在数据库系统层面上解决了两个问题:
- 城市级故障容灾及读扩展能力。
- 城市级故障自动无损容灾的“新常态”方案
会员ID系统为支付宝提供基础的会员登录、限权、身份识别基础服务,是支付宝的重要基础设施之一。
用户登录、鉴权及用户信息管理等操作都强依赖该服务,因此对高可用和性能都有很高的要求,一方面要具备城市级故障容灾的能力,另一方面对读操作的延迟也有很高的要求。
传统“两地三中心”的解决方案在传统的解决方案中,通常会采用“两地三中心”来解决城市级故障的容灾问题,采用读写分离的方案来解决读操作的性能问题。
顾名思义,“两地三中心”通常指的是在两个城市的三个机房内,每个机房内有一个数据中心。这样可以确保在某个城市发生故障时,其他城市的数据中心仍然可以提供服务。
OceanBase “三地五中心”部署
OceanBase新增了read only zone机制,为支持“三地五中心”及读写分离的部署方式,OceanBase新增了read only zone机制。
和通常的read write zone不同的是,read only zone中分区的副本都是只读副本,即该副本只参与和全功能(read/write)副本之间的日志同步,但不参与paxos协议的投票。增加read only zone可以有效扩展整个集群对外提供的读能力,同时不会增加写操作的响应时间。
通过在相应的城市和地区增加read only zone,本地的业务系统可以就近读取数据,一方面缩短了读操作的响应时间,同时也增大了系统的吞吐率,可以线性扩展整个集群的读能力。
在成本上,相对于原先的单独部署一套多副本的读库来说,有了大幅度的降低。
带有read only zone的“三地五中心”部署方式,大大降低了系统运维的复杂度。 对DBA来说,只需要部署一套OceanBase集群并且根据需要创建几个zone(read/write或者read only),就既可以解决城市级故障容灾的问题、又能够扩展读操作的能力。