OceanBase 架构原理深入

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

相关推荐
云贝教育-郑老师2 小时前
【OceanBase 的多租户架构是怎样的?有什么优势?】
数据库·oceanbase
BPM6662 小时前
2026流程管理软件选型指南:从Workflow、BPM到AI流程平台(架构+实战)
人工智能·架构
Volunteer Technology2 小时前
中间件场景题归纳
中间件·面试·架构
Shining05963 小时前
AI 编译器系列(七)《(MLIR)AscendNPU IR 编译堆栈》
人工智能·架构·mlir·infinitensor·hivm·ascendnpu ir
GJGCY3 小时前
中小企业财务AI工具技术评测:四大类别架构差异与选型维度
大数据·人工智能·ai·架构·财务·智能体
飞Link4 小时前
具身智能核心架构之 Python 行为树 (py_trees) 深度剖析与实战
开发语言·人工智能·python·架构
九河云4 小时前
云上安全运营中心(SOC)建设:从被动防御到主动狩猎
大数据·人工智能·安全·架构·数字化转型
我真会写代码4 小时前
深入理解JVM GC:触发机制、OOM关联及核心垃圾回收算法
java·jvm·架构
码路高手4 小时前
Trae-Agent中的Function Calling逻辑分析
人工智能·架构