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

相关推荐
ai产品老杨5 小时前
【深度架构】从GB28181到边缘计算:基于Docker与异构计算的AI视频管理平台深度解析
人工智能·架构·边缘计算
国科安芯6 小时前
空间激光通信系统中抗辐射 MCU 芯片应用研究
单片机·嵌入式硬件·架构·risc-v·安全性测试
机器小乙6 小时前
AI客户端架构演进:从套壳插件到C++原生护城河
c++·人工智能·架构
qcx236 小时前
Warp源码深度解析(三):Block-Based终端引擎——Grid模型、PTY与Shell Integration
人工智能·设计模式·架构·wrap
yongyoudayee6 小时前
AI原生 vs +AI:从技术架构看企业SaaS的未来路径
人工智能·架构·ai-native
AI服务老曹7 小时前
架构实战:如何基于 GB28181 与异构计算构建跨平台(X86/ARM)AI 视频管理系统?源码交付深度解析
arm开发·人工智能·架构
不老刘7 小时前
破局 EMR 痛点:如何化解“护理记录跨页”与“A4物理打印”的架构冲突
前端·架构
Swift社区7 小时前
传统游戏引擎 vs 鸿蒙 System 架构
架构·游戏引擎·harmonyos
IT枫斗者15 小时前
前端部署后如何判断“页面是不是最新”?一套可落地的版本检测方案(适配 Vite/Vue/React/任意 SPA)
前端·javascript·vue.js·react.js·架构·bug