OceanBase 架构原理深入

OceanBase 架构原理深入整体架构全景Zone 3机房3Zone 2机房2Zone 1机房1SQL 请求Paxos 同步Paxos 同步客户端 / 应用OBProxy 层连接代理路由 SQL 到正确的 OBServerOBServer-ALeaderOBServer-BFollowerOBServer-CFollowerRootService全局管理中枢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 对比对比项OracleOceanBase存储结构BTreeLSM-Tree写入方式随机写in-place update顺序追加写写性能受随机 IO 限制写放大小吞吐高类比操作表碎片整理 统计信息收集每日合并Major Compaction每日合并管理-- 手动触发合并sys 租户下执行ALTERSYSTEM MAJOR FREEZE;-- 查看合并进度SELECT*FROMoceanbase.CDB_OB_MAJOR_COMPACTION;-- 设置合并时间窗口凌晨2点开始ALTERSYSTEMSETmajor_freeze_duty_time02:00;[!warning] 注意合并期间 IO 压力较大建议设置在业务低峰期执行。三、分布式事务2PC Paxos单分区事务最常见最快SQL 只涉及一个分区 → 直接在该分区 Leader 上执行 → 通过 Paxos 同步给 Follower → 提交无需跨节点协调性能接近单机数据库。跨分区事务P1 Leader(Zone2)P0 Leader(Zone1)协调者P1 Leader(Zone2)P0 Leader(Zone1)协调者Phase 1 - PreparePhase 2 - CommitPrepare写日志Paxos确认Prepare写日志Paxos确认Prepare OKPrepare OKCommitCommit提交完成释放锁提交完成释放锁[!tip] 核心优势相比 MySQL 分库分表OceanBase原生支持分布式事务对应用完全透明无需业务层处理分布式事务逻辑。四、SQL 执行完整流程应用发送 SQLOBProxy解析SQL路由到对应LeaderParser词法/语法解析Resolver语义解析表名、列名Optimizer生成执行计划索引选择/分区裁剪Executor执行跨节点则并行下发子计划OBProxy返回结果给应用分区裁剪Partition Pruning[!tip] 与 Oracle 对比与 Oracle 分区表的 Partition Pruning 原理完全一致。-- 表按 user_id 哈希分区-- ✅ 可裁剪到单个分区性能最好SELECT*FROMordersWHEREuser_id12345;-- ❌ 无法裁剪扫描所有分区性能差SELECT*FROMordersWHEREorder_date2024-01-01;