为了提升分布式事务处理的性能并降低延迟，OceanBase 选择通过优化参与者和协调者（Coordinator）的操作，进一步改进传统的二阶段提交协议。
下图 6 展示了传统 2PC 与 OceanBase 2PC 的架构比较。与传统的 2PC 相比，OceanBase 2PC 中 Coordinator 不需要持久化状态，而是在故障恢复时由参与者共同协商。基于这种实现方案，prepare 成功即可应答用户，不需要等到第二轮 commit 成功再应答用户，从而将 Paxos 同步的次数从 3 个减少到 2 个，并将事务延迟进一步缩短为仅 1 个 Paxos 同步。当然，这种方案也增加了故障处理的复杂度。
自我刷新，两度创下 TPC-C 性能世界纪录
有了上述积累，OceanBase 团队向国际数据库权威测试 TPC-C 发起了挑战。
TPC 是一系列事务处理和数据库基准测试的规范。其中，TPC-C（Transaction Processing Performance Council）是针对在线事务处理（OLTP）的基准测试模型，使用一个商品销售模型对 OLTP 系统进行测试，可以比较好地观察出数据库服务的稳定性、性能以及容灾等特性。
TPC-C 测试中包含以下五类事务，包括：NewOrder 新订单的生成，Payment 订单付款，OrderStatus 最近订单查询，Delivery 交付配送，StockLevel 库存缺货状态分析。测试开始前，TPC-C Benchmark 会规定被试数据库的初始状态，并使用 tpmC 值（Transactions per Minute）衡量系统最大有效吞吐量（MQTh，Max Qualified Throughput）。
2019 年 10 月，OceanBase 成功通过 TPC-C 测试，并以 6088 万 tpmC 的在线事务处理性能，创下了当时的世界纪录。2020年 6 月，OceanBase 再次参与测试并二度登顶 TPC-C 榜单，以超过 7.07 亿 tpmC 的成绩，刷新了自己之前的纪录。
同样值得关注的，还有 OceanBase 在测试中所展现出的各项服务的稳定性，这个我们稍后看论文。
严苛的 TPC-C 基准测试
就像任何合格的产品在销售前要经过有关部门与行业协会的审批与认准一样，通过国际事务委员会（TPC）的 TPC-C 测试，说明了一个数据库系统通过了国际认证，可以与全世界的数据库产品同台竞技。
OceanBase 论文披露了第二次 TPC-C 基准测试的技术细节。拓扑结构如下图 7 所示，共部署 2360 台阿里云 ECS 服务器，并使用 400 台远程终端模拟器（remote terminal emulator，RTE）来模拟 559,440,000 个用户。同时部署 400 台网络服务器，每个网络服务器接收来自数个 RTE 的请求，通过 OceanBase 的 SQL 引擎将 TPC-C 事务实现为 SQL 存储过程，并通过开放式数据库连接（ODBC）调用数据服务器。
再说 OceanBase 集群，它由 1557 台服务器组成，采用 Share Nothing 架构连接。每台服务器具有 84 个 vCPU（2.5GHz Intel Xeon Platinum 8163 Skylake 超线程处理器），712GB RAM 和 3.5TB*4 SSD。这些服务器平均分成 3 个可用区，每个区域部署 519 台服务器。
作为一个分布式数据库，在 TPC-C 这个原本为集中式数据库而设的基准上取得如此成绩，OceanBase 团队遇到并解决了以下四个挑战。
第一个挑战是基准规范的持久性要求。测试时，OceanBase 数据库系统在商用硬件上运行，选择了具有 3 个区域部署的单个 Region。每个 Paxos 组由 3 个副本组成，即全能型副本、数据型副本和日志型副本。相较于使用 3 个全能型副本，这种配置将 MemTable 使用的 RAM 减少 2/3，将基线数据使用的存储减少 1/3。此外，通过消除数据型副本和日志型副本上重做的 redo log，某些 CPU 周期也得以缩短。
第二个挑战是关于生成基准测试初始数据的耗时过程。考虑到每个仓库（TPC-C 的基本数据单元）的行数（499,000 ）、每个 OceanBase 节点的仓库数（共计55,944,000 和 36,000）以及所需数据量，基础测试的初始数据生成任务非常繁重。
为了缩短初始数据生成时间，OceanBase 集群首先配置为 1 个副本，而不是 3 个副本和 no-logging。另外，在初始数据生成期间通过单个事务将数千个行批量插入数据库。所有初始数据插入后，OceanBase 被重新配置为 3 个副本，即全能型副本、数据型副本和日志型副本，然后分区得以自动重新复制和重新平衡。No-logging 也被关闭，并且系统在完成上述重新复制、重新平衡以及主要压缩后准备好进行测试。
第三个挑战是 ITEM 表。由于 ITEM 表在 TPC-C 基准上被事务频繁地访问，因此应该在每个 OceanBase 节点上进行复制，以避免远程访问并保证性能。此外，对于 ITEM 表上的任何事务而言，都必须满足 ACID 属性。因此，ITEM 表被配置为了一个同步复制表。
第四个挑战是根据 TPC-C 基准规范，基准测试测量间隔期间累积性能吞吐量的变化不应超过 2%。对于 OceanBase 而言，它有几个后台操作，比如次要压缩、 混合压缩 （将几个次要压缩合并为一个）以及将次要压缩从全能型副本复制到数据型副本。所有后台操作的 CPU 线性池得到保留以将性能吞吐量变化降至最低。
此外，MemTable 大小的上限应该选得足够小，以便在 RAM 被新事务耗尽之前完成次要压缩。它还必须足够大以利用每个节点 RAM 并产生最少的次要压缩。最后，8 小时基准测试测量间隔期间的性能吞吐量累积变化小于 1%。
详细性能结果
使用上述配置，TPC-C 基准测试分别在 3、9、27、81、243、510 和 1554 台服务器的 OceanBase 集群上运行，测试间隔为 8 小时。结果如下图 8 所示，tpmC 性能分数随着数据节点的增加呈线性上升，具有高度扩展性，在 1554 台服务器上运行时超过 7.07 亿，这一新的世界纪录相较 2019 年 10 月 OceanBase 自己创造的 6088 万 tpmC 提升了近 11 倍。
新订单（New-Order）响应时间如下图 10 所示。图 10(a) 报告了新订单事务类型的最大、90％、平均和最小响应时间曲线图，后三项数值基本重合。最小响应时间为 103 ms，平均和 90％ 响应时间接近，最小与最大差距分别为 5ms 和 33ms。图 10(b) 展示了新订单响应时间分布，其中绝大多数新订单事务在 20ms 内完成。
