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 对比

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

每日合并管理

-- 手动触发合并（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
    → 提交

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

跨分区事务

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

---

四、SQL 执行完整流程

分区裁剪（Partition Pruning）

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

-- 表按 user_id 哈希分区

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

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

---