OceanBase是如何实现服务的高可用和数据的高可靠

453 阅读5分钟

背景介绍

OceanBase 数据库是阿里巴巴和蚂蚁集团不基于任何开源产品,完全自研的原生分布式关系数据库软件,在普通硬件上实现金融级高可用,首创"三地五中心"城市级故障自动无损容灾新标准,具备卓越的水平扩展能力,全球首家通过 TPC-C 标准测试的分布式数据库,单集群规模超过 1500 节点。 产品具有云原生、强一致性、高度兼容 Oracle/MySQL 等特性, 承担支付宝 100% 核心链路,在国内几十家银行、保险公司等金融客户的核心系统中稳定运行。

一. OceanBase与传统数据库的比较

image.png

二. OceanBase集群架构

image.png

基础概念介绍

1. Zone

我们都知道多台服务器构成一个集群, 而Zone相当于是集群中的机器分组标签, 而这个分组的标签粒度可以是同机房的不同机柜, 同城的不同机房, 甚至是不同的城市,为了符合多派发原则, 建议zone的个数>=3, 并且是奇数 ,并且每个zone中有且都有一份完整的数据(称为副本),从而做到单个zone异常时,其他zone只要能正常工作, 那业务就不会受影响。

2. OB Service

我们把集群中每台服务器称为一个OB Service,每个OB Server都相对独立,都有独立计算和存储引擎,多个OB Service构成一个Zone, 多个Zone构成一个OceanBase集群

如图为集群,Zone和OB Service的关系

image.png

3. 资源池

在了解资源池之前, 我们先了解租户的概念, 租户类似于我们传统数据库中的实例, 在这个实例上,

  • 可以创建自己的用户(不同的用户名和密码)
  • 我们可以创建数据库(database),表(table)等所有客体对象
  • 有自己独立的information_schema等系统数据库
  • 有自己独立的系统变量
  • 数据库实例所具备的其他特性

而这个实例除了以上特性外,最重要的就是指定他占用资源情况, 这个资源池就是定义分配给这些租户的规格(CPU, 内存, 存储, TPS, QPS等)。最终我们发现整个集群可以按照制定规格划分为多个资源池, 分配给不同的租户,形成多租户机制,而租户与租户之间资源隔离(CPU逻辑隔离,内存物理隔离), 数据隔离。

4. Unit

每个Unit可以视为一个轻量级虚拟机,包括若干CPU资源,内存资源,磁盘资源等。作为资源的规格单位,一个资源池可以由多个Unit组成。

image.png

这个特别需要注意每个Unit只能属于一个租户,一个租户在一个OB Service上最多有一个UNIT。

5. 分区

当一个表很大时,可以水平拆成若干个分区,每个分区包含表的若干个行记录,每一个分区,还可以用不同的维度再分若干分区,叫做二级分区, 分区是OceanBase数据架构的基本单元,是传统数据库的分区表在分布式系统上的实现

6. 副本

为了数据安全和提供高可用的数据服务,每个分区的数据在物理上存储多份,每一份叫做分区的一个副本。副本根据负载和特定的策略,由系统自动调度分散在多个Server上。副本支持迁移、复制、增删、类型转换等管理操作。

如图是按照user_id分为3个分区(红, 蓝, 黄),每个一级分区再按时间分为4个分区

image.png

三. Paxos协议与负载均衡

image.png

多副本一致性协议

OB的每个分区都有多份副本, 多副本会自动选举主副本,主副本提供服务(如图黄色副本供应用访问,蓝色副本用于备份),从而保证数据可靠性和服务高可用性。 那多副本是如何确保数据持久化的呢?其实和传统型数据库一样, OB也是通过Redo-Log, Paxos组成员(同分区不同副本组成Paxos组)通过Redo-Log的多数派发强同步, Leader无需等待所有Follwer的反馈,多数派完成同步即可向应用反馈成功。 举个例子

  1. 应用写数据到P2分区。Zone2-OBservice1的P2为主副本(Leader), 承接业务需求
  2. 将Redo-Log同步请求发送到Zone1-OB Service1和Zone3-OB Service1的P2从副本(Follwer)
  3. 任何一个Follower完成Redo-Log落盘并将响应返回给 Leader后,Leader即认为Redo-Log完成强同步,无 需再等待其它Follower的反馈
  4. Leader反馈应用操作完成
自动负载均衡

主副本均匀打散到各个服务器中,使得各个服务器都能承载业务流量。(如图应用1、2、 3读请求分布路由到不同的OB Server);

智能路由

每台OB Server均可以独 立执行SQL,如果应用需要访问的数据在不同机器上, OB Server自动将请求路由至数据所在的机器,对业务完全透明(如应用2->P6->P7/P8)。

四. 动态扩容和缩容

随着业务的发展,系统会存在数据库资源不足需要水平扩容或者数据库资源空闲率过高需要水平缩容的操作, 而OB底层技术架构能够很好地支持这样的动态扩容和缩容

image.png 如图所示, 假设一个三副本的集群, 每个Zone都有3000个分区的副本,扩容后, OB自动将1500个分区的副本(含主副本)迁移到新服务器中的资源Unit中

动态扩容和缩容基本步骤如下:

image.png

整个扩容过程是在线动态扩容,对业务无感, 可以降低运维难度,从而很好地帮助业务线性地进行扩容和缩容,低成本的应对大型促销等活动

另外OB的扩容不仅支持集群的扩容, 同时也支持租户的扩容(如租户的资源单元由3个Unit变成6个Unit,当然一个租户的Unit数<=单个Zone的OB Service数)。