OceanBase集群技术架构

说明

• 本文章学习自OceanBase官方培训资料，仅供学习、交流

一 Paxos协议与负载均衡

1.1 数据分区与分区副本

分区

• 当一个表很大的时候，可以水平拆分为若干个分区，每个分区包含表的若干行记录。根据行数据到分区的映射关系不同，分为hash分区，List分区（按列表），range分区（按范围）等
• 每一个分区，还可以用不同的维度再分为若干分区，叫做二级分区
• 分区是OceanBase数据架构的基本单元，是传统数据库的分区表在分布式系统上的实现

---

副本

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

---

• 例如，交易记录表，按照用户ID分为3个hash分区（红、蓝、黄），每个一级hash分区再按照交易时间分为4个range分区
  

1.2 副本类型

根据存储数据种类的不同，副本有几种不同的类型，以支持不同业务在在数据安全，性能伸缩性，可用性，成本等之间进行取舍折中

• 全能型副本：目前支持的普通副本，拥有事务日志，MemTable和SSTable等全部完整的数据和功能。它可以随时快速切换为leader对外提供服务
• 日志型副本：只包含日志的副本，没有MemTable和SSTable。它参与日志投票并对外提供日志服务，可以参与其他副本的恢复，但自己不能变为主提供数据库服务。因为日志型副本所消耗的物理资源（CPU、内存、磁盘）更少，它可以有效降低最后一副本机器的成本，进而降低整个集群的总体成本
• 只读型副本：包含完整的日志，MemTable和SSTable等，但是它的日志比较特殊。它不作为paxos成员参与日志的投票，而是作为一个观察者实时追赶paxos成员的日志，并在本地回放。这种副本可以在业务对读取数据的一致性要求不高的时候提供只读服务。因其不加入paxos成员组，又不会造成投票成员增加导致事务提交延时的增加

类型	Log	MemTable	SSTable	数据安全
全能型	有，参与投票	有	有	高
日志型	有，参与投票	无	无	低
只读型	有，但不属于paxos组，只是listener	有	有	中

• 一个分区在一个zone中最多有一个全功能或日志型副本。只读型副本在同一个zone可以有多个

1.3 多副本一致性协议

• 以分区为单位组建Paxos协议组：每个分区都有多份副本（Replica），自动建立Paxos组，在分区级用多副本保证数据可靠性和服务高可用，数据管理更加灵活方便
  
• 自动选举主副本：OB自动生成多份副本，多副本自动选举主副本，主副本提供服务（如图黄色副本供应用访问，蓝色副本用于备份）

1.4 自动负载均衡

• 自动负载均衡：主副本均匀打散到各个服务器中，使得各个服务器都能承载业务流量。(如图应用1、2、3读请求分布路由到不同的OB Server）
• 每台OBServer相互独立：每台OBServer均可以独立执行SQL，如果应用需要访问的数据在不同机器上OBServer自动将请求路由至数据所在的机器，对业务完全透明（如应用2->P6->P7/P8)
  

1.5 数据持久化

通过多副本同步Redo Log确保数据持久化

• Paxos组成员通过Redo-Log的多数派强同步，确保数据的持久化
• Leader无需等待所有Follower的反馈，多数派完成同步即可向应用反馈成功

---

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

1.6 智能路由

• OB Proxy为应用提供智能路由服务，应用透明访问
  
  高效路由转发
• 对SQL做基本解析，确定对应Leader所在机器
• 反向代理，将请求路由至对应Leader；Leader位置无法确定时随机选择OB Server
• 轻量SQL解析 + 快速转发，保证高性能，单OB Proxy每秒转发百万次请求

“非”计算节点，无状态

• 每个OB Proxy是一个“无状态”的服务进程，不做数据持久化，对部署位置无要求
• OB Proxy不参与数据库引擎的计算任务，不参与事务（单机 or 分布式）处理
• 多个OB Proxy之间无联系，可通过F5/SLB组成负载均衡集群
• 不需要独立服务器，可以与OB Server共用一台服务器，如果应用对实时性要求高，也可以将OB Proxy部署到应用服务器中

Primary Zone

• 通过设置Primary Zone，将业务汇聚到特定Zone
  
• 通过为不同的租户配置不同的Primary Zone，可以将业务流量集中到若干Zone中，减少跨Zone及跨服务器的操作。Zone List，逗号两侧优先级相同，分号左侧优先级高于右侧

---

• Primary Zone有租户、数据库和表不同的级别
  
• 如无特殊指定，自动继承上级对象的primary_zone：database继承租户的primary_zone设置，table继承database的primary_zone设置
• database和table可以指定各自的primary_zone，不必和上一级对象的设置保持一致；提供更加灵活的负载均衡策略

1.7 Table Group

• Table Group，将多个表的相同分区ID的主副本聚集在一个OB Server中，减少分布式事务引入的开销
  
• 如果多个表的分区方式完全相同（分区类型、分区键个数、分区数量等） ，可以在逻辑上将这些表归属到同一个Table Group中，以影响动态负载均衡的策略
• 同一个Table Group中的所有表，分区ID（partition_id）相同的所有分区，它们的leader在同一个observer上；在不影响全局负载均衡的前提下，可有效减少分布式事务引入的跨机访问开销
• 如果负载均衡被打破（服务器故障后、扩容缩容等），Table Group中的所有表会作为一个整体来调整分区分布和leader分布
• 动态创建和删除，并且对上层应用完全透明
• 如果租户的unit_num=1且primary_zone只有一个zone，不需要tablegroup

---

• Table Group举例
  

二 动态扩容和缩容

2.1 动态水平扩展

• 假设一个三副本的集群，每个Zone都有3000个分区的副本，扩容后，OceanBase自动将1500个分区的副本（含主副本）迁移到新服务器中的资源Unit中

2.2 动态扩容和缩容技术实现

• 假设一个表有8个分区，扩容后，在每个Zone内，OceanBase自动将4个分区的副本（含有主副本）迁移到新服务器的租户资源单元
  中，实现Zone内各个OB Server的负载均衡。整个扩容过程是在线动态扩容，对业务无感知，可以降低运维难度
  

2.3 扩容基本步骤

1. 为每个zone添加新的物理机器
2. 在每台新添加的机器上，以正确的方式启动observer服务
3. 为每个新添加的observer进程执行alter system add server;命令，将observer服务添加到集群中
4. 执行alter resource pool unit_num = ;命令，扩充资源池中的unit个数
5. OceanBase自动启动“rebalance”过程，将部分数据从旧的unit在线复制到新的unit上。此过程可能会花费数十分钟，具体时间取决于数据量
6. 每个分区的数据复制完成后，OceanBase自动将服务切换到新的unit上，并删除旧unit中分区上的数据数据复制的过程是否已经完成。查看__all_virtual_sys_task_status表，是否有comment like '%partition migration%'的任务

2.4 租户扩容

• 租户扩容：通过扩大资源池规格实现纵向扩展
  
• 租户扩容 – 通过增大资源池Unit Num实现横向扩展
  
• 租户扩容 – 增加系统可用性三副本扩容至五副本
  

2.5 缩容基本步骤

1. 执行alter resource pool unit_num = ;命令，缩减资源池中的unit个数
2. OceanBase自动启动“rebalance”过程，将一部分数据从待下线机器上的unit在线复制到同zone内其它机器的unit上
3. 每个分区的数据复制完成后，OceanBase自动将服务切换到新的unit上，之后删除待下线机器的unit中分区上的数据
4. 为每台要下线的机器执行alter system delete server;命令，完成机器下线的操作
5. 手工终止已下线机器上的observer进程，并执行关机等操作

• 数据复制的过程是否已经完成？查看__all_virtual_sys_task_status表，是否有comment like '%partition migration%'的任务

三 数据可靠及高可用

3.1 灾难恢复能力等级

• 系统发生故障（掉电、宕机、进程误杀等）时，业务如何考察系统的“高可用”能力
• RTO（Recovery Time Objective)恢复时间目标：在故障或灾难发生之后，数据库停止工作的最高可承受时间，这是一个最大可容忍时限，必须在此时限内恢复数据=服务可用性
• RPO（Recovery Point Object)恢复点目标：这是一个过去的时间点，当灾难或紧急事件发生时，数据可以恢复到的时间点，是业务系统所能容忍的数据丢失量=数据可靠性
  
• OceanBase RPO=0 RTO<30秒，意味着当少数派故障时，OceanBase能够在30秒内恢复业务，且不会丢失任何数据。

3.2 高可用性

• OceanBase基于通用PC服务器提供高可用性
  
  少数派故障时自动实现服务接管，保证服务高可用
• 举例：Leader副本故障
  
• 假设Zone3-OB Server2故障，P7 Leader主副本无法正常提供服务
• 位于Zone1的P7 Follower从副本和Zone2的P7 Follower从副本将重新选出新的Leader，并接管业务
• 整个过程无需人工干预，自动完成
• Zone3-OB Server2故障恢复后，P7副本首先追平数据，数据追平后，继续参加Paxos组，一般情况下，该P7副本还会是主副本（以实现负载均衡）

举例：Follower从副本故障

• 假设Zone3-OB Server2故障，从副本（P5,P6,P8) 本来就不承接业务，剩下的2个副本依然满足多数派，依然可以正常提供业务，对业务无影响
• 待从副本所在服务器故障恢复后，追平数据后继续加入Paxos组后依然是从副本

3.3 OB Server进程异常处理策略

• 如果OB Server进程异常终止，通过通过server_permanent_offline_time参数的值来判定是否进行“临时线下”处理。
  
• 由于进程异常终止时间不长，异常进程可能很快就可以恢复，因此OceanBase暂时不做处理，以避免频繁的数据迁移
• 此时P5-P8只有两份副本，虽然依然满足多数派，可以保证RPO=0，但存在风险
  
• OceanBase会将机器做“临时下线”处理，从其它zone的主副本中，将缺失的数据复制到本zone内剩余的机器上（需要有足够的资源），以维持副本个数
• 异常终止的observer进程恢复后会自动加入集群，如果已经做过“临时下线”处理，需要从本zone内其它机器上（或者其它zone内）将unit迁移过来

3.4 OceanBase容灾

3.4.1 同城三机房

• 同城3个机房组成一个集群（每个机房是一个Zone），机房间延迟一般在0.5 ~ 2ms之间
• 机房级灾难时，剩余的两份副本依然是多数派，依然可以同步Redo-Log日志，保证RPO=0
• 但无法应对城市级的灾难
  

3.4.2 三地五中心五副本

• 三个城市，组成一个5副本的集群
• 任何一个IDC或者城市的故障，依然构成多数派，可以确保RPO=0
• 由于3份以上副本才能构成多数派，但每个城市最多只有2份副本，为降低时延，城市1和城市2应该离得较近，以降低同步Redo-Log的时延
• 为降低成本，城市3可以只部署日志型副本（只有日志）

3.4.3 同城两机房“主-备”方案

• 同城三机房或者三地五中心的方案对基础设施要求太高。为了利旧企业现网的基础设施，OceanBase提供了同城两机房和两地三中心两种方案
  
• 每个城市都部署一个OceanBase集群，一个为主集群一个为备集群；每个集群有自己单独的Paxos group，多副本一致性
• “集群间”通过Redo-log做数据同步，形式上类似传统数据库“主从复制”模式；有“异步同步”和“强同步”两种数据同步模式，类似ODD中的“最大性能”和“最大保护”两种模式

3.4.3 两地三中心“主-备”方案

• 主城市与备城市组成一个5副本的集群。任何IDC的故障，最多损失2份副本，剩余的3份副本依然满足多数派
• 备用城市建设一个独立的3副本集群，做为一个备集群，从主集群”异步同步“或者”强同步“到备集群
• 一旦主城市遭遇灾难，备城市可以接管业务

四 分布式事务

4.1 分布式事务

• 分布式事务跨机执行时，OceanBase通过多种机制保证ACID
  

• OceanBase是一个原生的分布式架构，采用了多点无共享（即Shared-Nothing）的架构，在实现全局（跨机器）一致的快照隔离和多版本并发控制时，会面临分布式架构所带来的技术挑战
• OceanBase数据库利用一个集中式服务来提供全局一致的版本号。事务在修改数据或者查询数据的时候，无论请求源自哪台物理机器，都会从这个集中式的服务处获取版本号，保证所有的版本号单调向前并且和真实世界的时间顺序保持一致
  

4.2 两阶段提交保证事务原子性

两阶段提交包括以下两个阶段：

1. 提交准备阶段（Prepare Phase）：在这个阶段，事务的协调者（Coordinator）向所有参与者（Participants）发送准备提交的请求。参与者接收到请求后，会执行事务的操作，并将事务的日志记录到本地的redo log中。如果所有参与者都成功地执行了事务并准备好提交，那么它们会向协调者发送“同意”（Agree）的响应。

2. 提交确认阶段（Commit Phase）：在这个阶段，协调者根据参与者的响应情况来决定是否提交事务。如果所有参与者都返回了“同意”，那么协调者会向所有参与者发送提交的指令，参与者接收到后会正式将事务提交并将其结果持久化到磁盘。如果有任何一个参与者返回了“否决”（Abort），那么协调者会向所有参与者发送中止的指令，参与者接收到后会撤销事务的操作。

OceanBase两阶段提交协议特点

• 事务协调者和所有参与者都是高可用的
• 单机多分区事务，所有参与者都prepare成功即认为事务进入提交状态 ， 立 即返回客户端commit
• 全自动处理异常情况

五 多版本并发控制（MVCC）

MVCC核心功能

• 采用锁机制控制读写冲突时，加锁后其他事务无法进行读，导致读写竞争，影响读的并发度。MVCC可以有效解决该问题
• 全局统一的数据版本号管理，取自全局唯一的时间戳服务（GTS）
• “读”、“写”操作都要从GTS获取版本号；同一个租户内只有一个GTS服务，可以保持全局（跨机）一致性
• 修改数据：事务未提交前，数据的新旧版本共存，但拥有不同的版本号
• 读取数据：先获取版本号，再去查找小于等于当前版本号的已提交数据
• 写操作获取行锁，读操作不需要锁，有效避免读写锁竞争，提高读写并发度

六 事务隔离级别（Isolation Level）

• 保证全局数据一致性的隔离级别

事务并发问题

• 脏读：读取了未提交的数据
• 不可重复读：指的是在同一事务内，不同的时刻读到的同一批数据可能是不一样的（期间被别的事务更新数据)
• 幻读：指的是在同一事务内，在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据（期间被别的事务插入或者删除了数据）

---

OceanBase支持多种事务隔离级别

• 基于全局一致的数据版本号管理，以不同的版本号策略实现不同的隔离级别
• Oracle模式支持以下两种隔离级别，应用系统可以根据需求权衡使用任何一种隔离级别:
  • Read-Committed：避免脏读，存在不可重复读和幻读（默认）
  • Serializable：避免脏读、不可重复读、幻读
• MySQL模式支持读已提交、可重复读两种隔离级别
• 不支持脏读（Dirty-Read），只能获取已提交数据