OceanBase 详解：金融级分布式数据库

每年双十一零点，支付宝要在几秒内扛住全球最高的支付洪峰，支撑这套交易链路的自研数据库，就是蚂蚁集团的 OceanBase。它 2010 年在支付宝内部立项，先在金融核心场景锤炼了十年，2021 年又将内核代码开源。今天它既能跑成横跨三个地域、上千台服务器的大集群，也能装进一个 Docker 容器在笔记本上运行。本文按"定位、架构、兼容、高可用、选型、实战"的顺序展开，帮你判断这套金融级分布式数据库是否值得进入你的技术栈。

1、从双十一到开源

OceanBase 的故事要从支付宝说起。2010 年，阿里启动自研数据库项目，目标很直接：用普通服务器集群替代小型机加集中式商业库，扛住逐年翻倍的交易量。经过多年灰度验证，2016 年起 OceanBase 全面替代 Oracle，支撑支付宝核心交易与账务链路，这是国产数据库第一次真正接管互联网金融机构的核心系统。

榜单战绩是它出圈的起点。2019 年，OceanBase 以 6088 万 tpmC 首次登顶 TPC-C 榜单，成为第一个登顶该榜单的中国数据库；2020 年 5 月又用 1500 多台服务器、跨三个地域的集群刷出 7.07 亿 tpmC，把自己的纪录提高了约 11 倍，技术成果被数据库顶会 VLDB 2022 收录（VLDB 论文）。2021 年它还以 3024 万 QphH 刷新过 TPC-H 榜单（10000 GB 级别），证明分析负载同样能打。

生产落地也不止支付宝一家：网商银行从开业起就把核心系统全量架在 OceanBase 上，此后大量银行、证券、保险机构跟进，场景从支付清算延伸到信贷、理财与账务核心。

2021 年 6 月，蚂蚁把数据库内核开源（GitHub 仓库），社区版免费可用。版本节奏上 4.x 是长期主线：4.3 系列已维护到 4.3.5，企业版迭代到 4.6.0，社区版则率先进入 5.x 线——截至 2026 年 9 月，社区版最新为 V5.0.1_CE。对开发者而言，这意味着零成本就能摸到一套金融级内核。

2、核心架构与租户

一套最小 OceanBase 集群由两类进程组成：observer 是数据库内核，数据存储与计算都在它上面；obproxy 是无状态访问代理，负责路由与连接管理。数据按分区组织，每个分区的日志流以多副本分布在不同 Zone（通常对应不同机房），副本间通过 Multi-Paxos 协议强同步，写入获多数派确认即算提交。与常见的主从半同步复制不同，多数派机制不依赖任何单点确认：任意一个副本故障，剩余多数派会在秒级选出新主继续服务，副本数通常配置为三或五，这也是后面 RPO=0 的基础。

租户（tenant）是 OceanBase 最有特色的设计：一个集群里可以切出多个逻辑数据库实例，各自指定兼容模式（MySQL 或 Oracle）与资源配额（CPU、内存按 unit 划分），彼此资源隔离、权限隔离。集群自留一个 sys 租户做运维，业务全跑在普通租户里，效果类似"数据库里的虚拟机"，一套集群服务几十个业务互不干扰。

4.0 起官方提出单机分布式一体化：同一个 observer 二进制，既可以一台机器单进程跑，也可以在线扩成多机集群，SQL 与运维方式完全一致。整体结构如下图。

flowchart TD A[应用] --> B[OBProxy] B --> C[Zone 1 机房] B --> D[Zone 2 机房] B --> E[Zone 3 机房] C --> F[Paxos 副本组] D --> F E --> F F --> G[MySQL 租户] F --> H[Oracle 租户] I[单机部署] -. 同内核 .-> F

图里能看到三层信息：流量经 OBProxy 打到不同机房；同一份数据的副本组跨 Zone 由 Paxos 强同步；租户按兼容模式分别承接不同业务。而单机部署与这套分布式架构共享同一内核，这正是"一体化"的含义——小项目单机起步，业务涨了在线加节点，全程不换数据库。

3、MySQL 与 Oracle 双兼容

OceanBase 的兼容策略是"一个集群、两种方言"。MySQL 模式以 MySQL 5.7 语法为基准，协议层面直接说 MySQL 话：连上 2881 端口，mysql 客户端、JDBC 驱动、ORM 框架原样可用，官方另提供增强版命令行 obclient，用法与 mysql 客户端一致。Oracle 模式则是企业版能力，兼容常用 PL/SQL 对象，存储过程、包、触发器、序列都能直接迁移；社区版只提供 MySQL 模式（兼容模式文档）。

双兼容的价值在替换存量系统时体现得最充分。一个典型的银行核心下线 Oracle 路径是这样的：先用 OMS 迁移服务做全量加增量同步，Oracle 模式租户承接原有 PL/SQL 代码，业务几乎不用改 SQL；新旧库并行双跑、逐日对账，再按业务条线灰度切流。招商证券就用这套多租户能力做 DBaaS，在同一集群里批量交付 Oracle 与 MySQL 两种租户（招商证券案例）。

对社区版用户来说门槛更低：原本连 MySQL 的应用改个连接串就能落到 OceanBase，这也是多数团队第一次接触它的方式。

4、HTAP 与 TiDB 对比

谈国产分布式数据库，OceanBase 和 TiDB 总被放在一起。两者目标一致：一套系统同时承载交易与分析，省掉 ETL 双链路；但出身决定了路线差异。核心维度对比如下：

维度	OceanBase	TiDB
出身场景	支付宝交易内核，强事务优先	互联网海量数据，扩展性优先
存储形态	同内核行存加列存	TiKV 行存加 TiFlash 列存
SQL 兼容	MySQL 模式加 Oracle 模式	MySQL 协议兼容
副本协议	Multi-Paxos	Raft
最小形态	单机一体化部署	PD 与 TiKV 多组件起步
社区路线	金融政企与国产化场景	国际化开源社区

一句话概括：HTAP 是 TiDB 的起点，却是 OceanBase 的延伸。TiDB 从第一天就为分析配上 TiFlash 列存副本与 MPP 执行引擎；OceanBase 则先把金融强事务做到极致，再逐步补齐分析能力——4.3 引入列存表，4.3.3 加入向量类型与索引，企业版 4.6 进一步提供向量、全文、标量的原生混合搜索。两者也都同时提供开源自建与云上托管两种获取方式，选型更多看团队基因与既有生态，而非绝对优劣。

5、金融级高可用

金融场景对数据库最硬的要求是数据零丢失。OceanBase 的答案写在架构里：Paxos 多数派提交意味着每个已确认事务至少落在多数副本上，单副本故障、乃至整个机房掉电，多数派仍在，数据一条不丢，即 RPO=0；4.x 的自动选主与流量切换把恢复时间压到 8 秒以内（RTO < 8 秒），应用侧重连即可继续读写，无需人工介入。部署形态上，同城三机房可抗机房级故障，三地五机房可抗城市级故障，容灾等级按业务监管要求逐级选择。双十一大促期间不降级、不停服的底气正来源于此；对监管要求"已入账交易不得丢失"的银行核心系统，这是能通过评审的硬指标。

6、社区版与企业版

开源不等于全部免费，动手前先划清边界。依据官方功能差异文档，两版的核心区别如下（官方差异文档）：

能力	社区版	企业版
MySQL 模式	支持	支持
Oracle 模式	不支持	支持
内核能力	与企业版一致	与社区版同源
运维平台	OCP Express 轻量版	OCP 企业版
安全审计	基础能力	完整审计与加密
商业支持	社区渠道	专属订阅服务

自 4.0 单机分布式一体化架构起，社区版 MySQL 模式的内核能力与企业版完全一致，性能不打折。因此边界很清晰：MySQL 生态的业务系统、个人学习与中小规模生产，社区版都能覆盖；要 Oracle 兼容、完整审计合规与专属技术支持，才需要为企业版付费。

7、Docker 单机实战

官方 all-in-one 镜像把 observer 与 obproxy 打包在一个容器里，给容器预留 8 GB 以上内存即可体验。拉起命令如下：

docker run -d -m 10G \
  -p 2881:2881 -p 2883:2883 \
  --name obce \
  obpilot/oceanbase-ce:latest

2881 是 observer 直连端口，2883 是 obproxy 端口；首次初始化需要几十秒到几分钟，可用 docker logs -f obce 观察进度。容器内预置了 test 租户，进入容器直接连接：

docker exec -it obce bash
obclient -h127.0.0.1 -P2881 -uroot@test -A

-uroot@test 表示 test 租户的管理员，空密码直接登录。连上之后当 MySQL 用即可：

-- 验证 MySQL 兼容性
SELECT VERSION();
CREATE DATABASE demo;
USE demo;
CREATE TABLE account (
  id      INT PRIMARY KEY,
  name    VARCHAR(32),
  balance DECIMAL(12, 2)
);
INSERT INTO account VALUES (1, 'alice', 100.00), (2, 'bob', 250.50);
SELECT name, balance FROM account WHERE balance > 200;

上面这套语句与 MySQL 语法逐字相同，建库建表、写入查询一气呵成——这就是 MySQL 模式的意义：迁移成本约等于改一个连接串。想进一步体验租户隔离，可按官方文档在 sys 租户里创建资源单元再开新租户，感受"一个集群多个逻辑库"的设计；体验完用 docker stop obce 停掉容器即可，数据保留在容器卷里，下次 docker start obce 能接着用。

8、金融政企选型

为什么金融、政企场景点名 OceanBase？需求侧有四条硬理由。一是数据零丢失的监管底线，RPO=0 加城市级容灾是现成答案；二是 Oracle 存量替换，Oracle 模式加 OMS 迁移链路能把应用改造量压到最低，历史 SQL 资产大多原样保留；三是国产化与信创目录要求，OceanBase 及其全栈工具在名单之内，采购与验收路径顺畅；四是多租户带来的成本收敛，一套集群服务多个业务系统，资源利用率远高于一库一机。

反过来也要说清它不适合的场景：只用 MySQL 且规模不大的团队，单机 MySQL 或云 RDS 更省心；重度依赖 PostgreSQL 生态扩展（插件、GIS）的团队会水土不服；需要全球多云托管与国际化社区支持时，TiDB 的海外布局更成熟。金融级能力是为金融级需求准备的，普通业务不必为用不上的容灾指标买单。

9、总结

OceanBase 用十余年金融核心场景验证了一条完整路线：Paxos 多副本换来 RPO=0，租户隔离换来资源收敛，单机分布式一体化换来"从小到大不换库"，双兼容模式换来最低迁移成本，开源社区版则让这条路向所有开发者开放。对于金融、政企等对一致性与容灾有硬性要求的团队，建议认真评估企业版；对于想学习分布式数据库内核与兼容架构的开发者，社区版加 Docker 十分钟就能起步。

留三道练习：