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';