OceanBase 架构原理深入

整体架构全景

Zone 3（机房3）
Zone 2（机房2）
Zone 1（机房1）
SQL 请求
Paxos 同步
Paxos 同步
客户端 / 应用
OBProxy 层

连接代理，路由 SQL 到正确的 OBServer
OBServer-A

Leader
OBServer-B

Follower
OBServer-C

Follower
RootService

全局管理中枢

DDL / 负载均衡 / 元信息管理

一、Paxos 协议与选主流程

每个分区的三个副本构成一个 Paxos 组：

复制代码

分区 P0 的 Paxos 组：
  Zone1: OBServer-A  ← Leader（处理读写）
  Zone2: OBServer-B  ← Follower
  Zone3: OBServer-C  ← Follower

写入流程（强一致）

Follower(Zone3) Follower(Zone2) Leader(Zone1) 客户端 Follower(Zone3) Follower(Zone2) Leader(Zone1) 客户端写入请求生成 Redo Log 并行发送日志并行发送日志确认收到确认收到（多数派达成）提交事务返回成功

$!tip$ 与 Oracle 对比

类似 Data Guard 最大保护模式，但不需要所有备库确认，只需多数派（2/3）确认即可提交。

选主流程（Leader 故障时）

Follower(Zone3) Follower(Zone2) Leader(Zone1) ❌ Follower(Zone3) Follower(Zone2) Leader(Zone1) ❌ 获得多数派投票，成为新 Leader 心跳超时（2s）心跳超时（2s）发起投票请求投票同意补齐未完成日志恢复正常服务

$!important$ 高可用指标

RTO < 30秒（故障切换时间）

RPO = 0（零数据丢失）

二、LSM-Tree 存储引擎

数据完整生命周期

达到阈值 256MB

转储 Minor Compaction
积累多个

每日合并 Major Compaction
写入请求
MemTable

内存，可读写
Mini SSTable

磁盘，只读
基线 SSTable

完整数据快照

读取流程

有
无
有
无
读取一行数据
MemTable

有数据？
合并多版本

返回结果
Mini SSTable

有数据？
查基线 SSTable

$!note$ 性能特点

写性能极好：顺序追加写，避免随机 IO

读性能：依赖合并和缓存来优化，冷数据读取需合并多层

与 Oracle 对比

对比项	Oracle	OceanBase
存储结构	B+Tree	LSM-Tree
写入方式	随机写（in-place update）	顺序追加写
写性能	受随机 IO 限制	写放大小，吞吐高
类比操作	表碎片整理 + 统计信息收集	每日合并（Major Compaction）

每日合并管理

sql 复制代码

-- 手动触发合并（sys 租户下执行）
ALTER SYSTEM MAJOR FREEZE;

-- 查看合并进度
SELECT * FROM oceanbase.CDB_OB_MAJOR_COMPACTION;

-- 设置合并时间窗口（凌晨2点开始）
ALTER SYSTEM SET major_freeze_duty_time = '02:00';

$!warning$ 注意

合并期间 IO 压力较大，建议设置在业务低峰期执行。

三、分布式事务（2PC + Paxos）

单分区事务（最常见，最快）

复制代码

SQL 只涉及一个分区
    → 直接在该分区 Leader 上执行
    → 通过 Paxos 同步给 Follower
    → 提交

无需跨节点协调，性能接近单机数据库。

跨分区事务

P1 Leader(Zone2) P0 Leader(Zone1) 协调者 P1 Leader(Zone2) P0 Leader(Zone1) 协调者 Phase 1 - Prepare Phase 2 - Commit Prepare（写日志，Paxos确认） Prepare（写日志，Paxos确认） Prepare OK Prepare OK Commit Commit 提交完成，释放锁提交完成，释放锁

$!tip$ 核心优势

相比 MySQL 分库分表，OceanBase 原生支持分布式事务，对应用完全透明，无需业务层处理分布式事务逻辑。

四、SQL 执行完整流程

应用发送 SQL
OBProxy

解析SQL，路由到对应Leader
Parser

词法/语法解析
Resolver

语义解析：表名、列名
Optimizer

生成执行计划

索引选择/分区裁剪
Executor

执行

跨节点则并行下发子计划
OBProxy
返回结果给应用

分区裁剪（Partition Pruning）

$!tip$ 与 Oracle 对比

与 Oracle 分区表的 Partition Pruning 原理完全一致。

sql 复制代码

-- 表按 user_id 哈希分区

-- ✅ 可裁剪到单个分区，性能最好
SELECT * FROM orders WHERE user_id = 12345;

-- ❌ 无法裁剪，扫描所有分区，性能差
SELECT * FROM orders WHERE order_date = '2024-01-01';