OceanBase 架构原理深入

OceanBase 架构原理深入

整体架构全景

一、Paxos 协议与选主流程

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

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

写入流程（强一致）

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

选主流程（Leader 故障时）

[!important] 高可用指标

• RTO < 30秒（故障切换时间）
• RPO = 0（零数据丢失）

二、LSM-Tree 存储引擎

数据完整生命周期

读取流程

[!note] 性能特点

• 写性能极好：顺序追加写，避免随机 IO
• 读性能：依赖合并和缓存来优化，冷数据读取需合并多层

与 Oracle 对比

每日合并管理

-- 手动触发合并（sys 租户下执行）ALTERSYSTEM MAJOR FREEZE;-- 查看合并进度SELECT*FROMoceanbase.CDB_OB_MAJOR_COMPACTION;-- 设置合并时间窗口（凌晨2点开始）ALTERSYSTEMSETmajor_freeze_duty_time='02:00';

[!warning] 注意
合并期间 IO 压力较大，建议设置在业务低峰期执行。

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

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

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

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

跨分区事务

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

四、SQL 执行完整流程

分区裁剪（Partition Pruning）

[!tip] 与 Oracle 对比
与 Oracle 分区表的 Partition Pruning 原理完全一致。

-- 表按 user_id 哈希分区-- ✅ 可裁剪到单个分区，性能最好SELECT*FROMordersWHEREuser_id=12345;-- ❌ 无法裁剪，扫描所有分区，性能差SELECT*FROMordersWHEREorder_date='2024-01-01';