国际顶会+2！实现云原生共享存储架构创新，支撑百万级分区、高频迁移分布式 OLTP

编者按

今天，是最新的两篇技术论文分享。此前，由 OceanBase 团队撰写的两篇论文被数据库领域国际顶级会议 VLDB 2026 正式录用。两篇论文分别介绍了 OceanBase 在“云原生共享存储架构”方向上的工程突破与创新实践，以及在海量分区、动态负载均衡与跨分区分布式事务场景下的核心突破。目前，这两项创新成果均在 OceanBase 生产体系中落地，并取得显著成效。

全文 3960 字，阅读约需 5 分钟，以下为论文内容和核心技术介绍：

论文《OceanBase Bacchus: a High-Performance and Scalable Cloud-Native Shared Storage Architecture for Multi-Cloud》系统阐述了 OceanBase Bacchus 在“云原生共享存储架构”方向上的工程突破与创新实践。论文提出面向服务的 PALF 共享日志、共享块缓存服务、多层缓存与预热机制等核心技术创新，为新一代云原生数据库的设计提供了完整参考。

OceanBase Bacchus（即 OceanBase 4.4.x）是 OceanBase 自研的分布式云原生共享存储数据库系统，在保留完整 ACID 事务能力的同时，实现了存算分离、弹性扩缩容与多云原生部署，已在公有云产品中完成规模化落地。

在 SysBench、TPC-H、TPC-DS、ClickBench 等主流基准测试中，OceanBase Bacchus 在 OLTP 场景下将存储成本降低 59%（OLTP）和 89%（OLAP）。

100TB 数据量下Bacchus 与前代 OceanBase 存储成本对比

OceanBase Bacchus 拥有三大核心技术。

核心技术一：基于 PALF 的共享日志服务化

传统共享日志架构（如Aurora、Socrates）采用单写入者（Single-Writer）模式，所有写入都通过主节点追加到共享日志，存在明显的主节点瓶颈。Bacchus 通过引入PALF日志服务解决问题。

设计核心：分片日志流 + 多读写 Leader

图1：PALF共享日志示意图

Bacchus 采用面向服务的日志架构，基于 OceanBase 自研的 PALF（Paxos-based Append-only Log Framework）共识协议实现：

日志分片（Log Stream Sharding）：数据被划分为多个日志流，每个流对应一个逻辑分区。每个流有独立的 Leader 负责向 PALF 追加提交日志（CLog），单流单写入者避免了日志层的写入冲突。
水平扩展：多个 RW（读写）节点通过领导不同的日志流实现写入的水平扩展，打破了经典共享日志的单写入者瓶颈。
ACID 保障：跨分区事务通过分布式 2PC（两阶段提交）协调多个流 Leader，在实现分区级并行的同时保证全局事务一致性。

RPO = 0 的可靠性

Bacchus 分离了两条持久化路径：

提交路径（RPO=0）：事务提交仅在 CLog 通过 PALF 复制并被多数派LogServer 持久化后才向客户端确认，确保数据零丢失。
归档路径（PITR）：近实时归档异步将日志上传到对象存储，用于时间点恢复和快照，归档进度不影响事务提交。默认部署中，每个 PALF 流在三可用区（AZ）的三台 LogServer 上复制（2-of-3提交），即使单 AZ 故障也能保证 RPO=0。

核心技术二：共享块缓存服务

对象存储的单次读取延迟高达50–100ms，远超 OLTP 毫秒级响应要求。Bacchus 设计了三层缓存架构，在对象存储与 OLTP 之间搭建高性能缓存层。

图2：三层缓存架构

三级缓存层次结构

内存缓存（Memory Cache）：最热数据常驻内存，微秒级访问，用于存储最热的微块和索引数据。
本地持久化缓存（Local Persistent Cache）：本地云盘缓存，跨重启保持数据，缓解缓存雪崩和冷启动延迟，同时作为写入缓存持久化元数据和最新变更日志。
分布式共享缓存（Distributed Shared Cache）：在各 AZ 内部署BlockServer 集群，以宏块粒度缓存温数据，供同 AZ 的 RW/RO 节点共享，消除冗余副本。

缓存预热机制

OceanBase Bacchus 提供多种预热策略确保缓存命中率：基线切换预热、主从预热、复制迁移预热、弹性扩缩容预热。生产环境实测显示，OLTP 场景下私有宏块缓存命中率保持 100%，共享宏块和整体命中率接近 100%，对象存储读取被有效屏蔽。

核心技术三：LSM-Tree + 对象存储的深度融合

OceanBase充分利用 LSM-tree 与对象存储的天然契合——LSM-tree 的 SSTable 采用追加写模式，与对象存储的追加特性完美匹配，避免了原地更新和写入冲突。

多级分离架构

存储与计算分离：无状态计算节点通过共享缓存和日志服务访问数据，支持独立弹性扩缩容。
日志与数据分离：CLog 使用低延迟云盘，老日志迁移到共享存储；持久数据存于对象存储，热数据缓存在本地。
前台与后台分离：压缩、DDL 等后台任务在独立进程中运行，与前台流量隔离，提升 CPU 利用率。
冷热数据分层：内存缓存最热数据，本地缓存热数据，对象存储冷数据，实现成本与性能的最佳平衡。

智能 Compaction 策略

图3：Bacchus的micro/mini/minor/major合并流程

图4：数据写入过程

Micro Compaction：在 Mini Compaction 之前进行micro compaction，生成micro SSTables，提前推进检查点，降低弹性扩缩容成本，加速故障恢复。
Major Compaction：主要在共享存储层独立运行，计算节点无感知，合并增量数据与基线数据。
Compaction 卸载：将计算密集的压缩任务卸载到空闲机器执行，进一步分离存储与计算。

多云原生支持

OceanBase Bacchus 通过 S3 兼容接口支持多云对象存储（AWS S3、阿里云 OSS、Azure Blob、MinIO 等），避免厂商环境限制，实现真正的灵活多云部署。

最后总结一下，基于这三项创新，构建了一套生产级的多云原生共享存储架构，实现了：

Stateless 计算节点：支持计算、缓存、存储独立弹性扩缩容
零数据丢失：RPO=0 的可靠性保障
极致成本优化：OLTP 存储成本降低 59%，OLAP 降低 89%
多云原生部署：支持 AWS、阿里云、Azure 等多云平台，避免厂商锁定
卓越性能表现：OLTP 与 HBase/Aurora 相当或更优，OLAP 显著超越StarRocks

基于实际部署经验，团队总结出九大工程洞见：

对象存储需要 I/O 聚合与批量操作；

按集群/租户隔离存储桶实现 I/O 隔离与独立计费；

多种分离策略（存算分离、读写分离、日志数据分离、前后台分离）缺一不可；

日志服务是计算节点无状态化和高性能的关键；

本地微块 + 共享宏块缓存组合效果最佳；

多级缓存预热与热数据自动识别至关重要；

基于日志服务的分层元数据管理高效可靠；

统一多云架构可服务 OLTP/OLAP/KV 多种负载；

弹性缓存扩容与监控是控制尾延迟的关键

未来，OceanBase 团队将持续探索对象存储 I/O 模式优化、自适应缓存调度、跨云容灾增强、以及 Serverless 数据库形态等方向，推动云原生共享存储架构从“可用”走向“极致高效”。

论文《A Tree-Structured Two-Phase Commit Framework for OceanBase: Optimizing Scalability and Consistency》，系统性阐述了 OceanBase 在海量分区、动态负载均衡与跨分区分布式事务场景下的核心突破：以日志流（Log Stream）替代传统「一分区一参与者」的 2PC 模型，提出树形两阶段提交（Tree-Shaped 2PC）框架，在保持 ACID 与线性一致性的同时，将协调开销降低数个数量级，并已在 OceanBase 4.x 生产体系中规模化落地。

OceanBase 在 4.0 起采用以日志流（Log Stream）为核心的架构，将共置在同一机器或资源单位上的分区 leader 映射到同一日志流，共享单机日志与 Paxos 复制。这为「以日志流为协调单元」提供了天然基础。

团队据此提出树形 2PC 框架，同时攻克静态事务极致性能与动态迁移下的一致性。

图1：迁移过程中递归构建的日志流树

核心技术一：日志流作为合并参与者

设计核心：从「按分区 2PC」到「按日志流 2PC」

在同一台机器上，多个分区共享一条日志流。框架将整条日志流注册为一个 2PC 参与者，而不是为每个分区单独注册。一笔触及 N 个共置分区的交易，在提交阶段只与一个日志流参与者交互。

效果：当 N=100 时，协调参与者数量减少约 99%；静态场景下事务延迟可逼近单机水平（论文中典型约 1.2 ms），显著降低 RPC 扇出、日志同步压力与参与者列表带来的网络带宽消耗。

这与「数据面仍以分区做并发控制」并不矛盾：分区仍是读写与锁的单元；原子性边界上移到日志流，从协调维度完成合并。

图2：按分区（3.x）与按日志流（4.x）的2PC 提交延迟对比

核心技术二：动态树形 2PC

设计核心：迁移中在线构造提交树，无需显式更新参与者列表

当分区在事务执行期间发生迁移时，源日志流在上下文中记录目标日志流，通过递归追踪形成一棵日志流树（Log Stream Tree）。定理保证：该树满足 ACID 所需的最小参与者集合要求。

在此基础上，树形 2PC 将协调者与参与者组织成树：

内部节点对其子节点充当协调者，对其父节点充当参与者；
Prepare/ Commit 消息沿树向下传播，降低相对「扁平协调者直连所有叶子」的扇出；
与经典 R* 层次 2PC 不同：节点是日志流而非静态站点，边可在提交过程中因迁移而动态出现。

迁移上下文作为叶子嵌入，避免显式维护全局参与者列表、化解循环依赖，并在拓扑变化下仍保证线性化提交。

延迟优化：协调者复用参与者日志、在收到全部 Prepare确认后即可应答客户端（不必等待协调者 Commit 日志落盘），在常见浅树和静态路径下将关键响应路径压缩为两轮 RPC + 一次关键 I/O。

图3：树形 2PC 状态机

图4：分区迁移与树形 2PC 并发时的参与者维护

核心技术三：未知状态机制

设计核心：参与者丢上下文时「不说谎」

层次 2PC 的经典隐患是：参与者回收上下文后，对重试请求可能返回错误的 Prepare 投票（「说谎参与者」），导致已提交事务被误中止。

图5：说谎参与者导致错误回滚

OceanBase 引入：

prepare_unknown trans_unknown：在既无完整上下文、也无可恢复的终态决策时，禁止伪造 Commit 或 Abort；
配合 TDT（Transaction Data Table）保留终态决策，服务重复与延迟请求。

从而在上下文丢失、协调者重建等场景下，既避免一致性破坏，又将用户侧歧义控制在可预期范围内。

图6：unknown状态与终态决策恢复

生产实践

论文 Production Experience 一节与实验形成呼应：

某移动核心与公有云 SaaS 场景，单库可达数十万至数百万分区；生产抓包曾见单笔事务 4000+ 参与者，某业务峰值 13 笔并发、每笔超 1.12 万分区级参与者，参与者列表元数据一度占超 50% 网络带宽。
3.x 压测：100 参与者约 1.66 ms → 1000 参与者 240 ms → 1 万参与者 7.54 s → 2 万参与者超 1000 s。
4.0 起迁移至日志流架构后，同类海量分区压测提交延迟稳定在约 60 ms，与实验结论一致。

运维侧，通过迁移前准入检查（积压事务过多则暂缓）、迁移并发控制与调度策略，避免同一日志流短时反复迁移，将提交树保持较浅，抑制迁移与大量在途事务重叠时的尾延迟抖动（内部分享曾出现单机上 5000+ 在途事务与迁移重叠导致数百毫秒级停顿的案例）。

总结一下：OceanBase 树形 2PC 框架通过三项核心创新——「日志流合并参与者」「动态树形提交协议」「未知状态 + 终态决策恢复」——在统一系统内同时实现：

静态跨分区事务：协调开销数量级下降，性能逼近单机；

动态弹性扩缩容：在线分区迁移下仍保持线性一致提交，无需昂贵的参与者列表重校验。

目前，该工作已在 OceanBase 4.x 生产路径中验证，支撑金融、互联网、公有云等场景下百万级分区、高频迁移的分布式 OLTP。未来，团队将继续在热点日志流负载均衡、更深提交树下的尾延迟治理、以及与 PALF 高吞吐日志的协同优化等方向深化，推动云原生数据库在“强一致”与“极致弹性”之间走得更远。