蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注，为了更清楚的展示其中的技术细节，我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读，共包括五篇：
1）TPC-C基准测试介绍
2）OceanBase如何做TPC-C测试
3）TPC-C基准测试之SQL优化
4）TPC-C基准测试之数据库事务引擎的挑战
5）TPC-C基准测试之存储优化
本文为第四篇，其它文章已同步发布，详情请在“蚂蚁金服科技”公众号查看。
OceanBase 这次 TPC-C 测试与榜单上 Oracle 和 DB2 等其他数据库在硬件使用上有非常大的不同，OceanBase 的数据库服务器使用的是 204+3 台型号是 ecs.i2.16xlarge 阿里云 ECS 服务器，其中 204 台作为 data node，还有 3 台作为 root node，每位读者都可以在阿里云网站上轻松按需购买。如果读者翻看 Oracle 和 DB2 的 TPC-C 测试报告会发现，这些数据库都会使用专用的存储设备，例如前最高记录保持者 Oracle 在 2010 年的测试，使用了 97 台 COMSTAR 专用的存储设备，其中 28 台用来存储数据库的重做日志（Redo Log）。
硬件的差异给软件架构提出了完全不同的挑战，专用的存储设备其内部通过硬件冗余实现了设备自身的可靠保证，数据库软件在使用这样的存储设备时就天然的预设了数据不会丢失。但是，这种方式带来了成本的极大消耗，专用的存储设备的价格都是特别昂贵的。
OceanBase 使用通用的 ECS 服务器提供数据库服务，并且只使用 ECS 机器自带的本地硬盘做数据存储，这是最通用的硬件条件。但是这种方式对软件架构提出了很大的挑战，因为单个 ECS 服务器的不如专用的存储设备可靠性高。这也对 OceanBase 的事务引擎提出了很大的挑战，OceanBase 是在普通的 ECS 服务器上就可以实现 ACID 特性。
TPC-C 测试是对事务 ACID 特性有完整并且严格的要求。下面分别介绍 OceanBase 针对事务 ACID 的特性的解决方案。
Paxos 日志同步保证持久性(Durability)
OceanBase 数据库的事务持久性（Durability）保证是依赖事务重做日志（Redo Log）的持久性来达成的。所有的 Redo Log 会实时强同步到另外两台数据库服务机器上，包含产生 Redo Log 的机器在内，总共会有三台机器在硬盘中持久化 Redo Log。OceanBase 采用了 Paxos 一致性同步协议来协调这三台机器上 Redo Log 的持久化，Paxos协议采用超过半数（也叫“多数派”）成功即算成功的算法（三个副本时，两个成功即超过半数），当其中两台机器完成持久化后，事务即可完成提交，剩下的一台机器的 Redo Log 在通常情况下，也是立即就持久化完成了。但如果这台机器碰巧出现异常，也不会影响事务的提交，系统会在其恢复后自动补齐所缺失的 Redo Log。如果机器永久故障，系统会将故障机器所应负责同步的数据分散给集群内的其他机器，这些机器会自动补齐所缺失内容，并跟上最新的 Redo Log 写入。
使用 Paxos 一致性协议的最大优势是数据持久化和数据库服务可用性（Availability）的完美平衡。当使用三个副本时，任何时候坏掉一个副本时至少还有另一个副本有数据，并且写入还可以持续，因为还剩下两个副本，后续的写入也不受影响。所以，OceanBase 在保证了事务持久性的同时，也大大提升了数据库的连续服务能力。TPC 组织的审计员在现场审计 OceanBase 持久性能力时，在客户端持续产生压力的情况下，从 OceanBase 集群中随意挑选了一台机器做了强制断电操作，发现数据库的数据不仅没丢，数据库不需要任何人工干预还能持续的提供服务，审计员们都很吃惊，并且对 OceanBase 大为赞赏。
依靠自动两阶段提交原子性(Atomicity)
TPC-C 测试模型的五种事务中的“订单创建”和“订单支付”两个事务分别会对很多数据做修改，是其中相对复杂的两个事务。TPC-C 标准对事务的原子性（Atomicity）是强制性的要求，要求一个事务内部对仓库、订单、用户等表格的修改一定要原子的生效，不允许出现只有一半成功的情况。
OceanBase 的数据是按照仓库 ID（Warehouse_ID）拆分到多台机器上的，如果所有的事务都是发生在同一个仓库内部，那么无论数据量有多大，事务的修改都只会涉及一台机器的数据，也就是在一台机器上完成事务提交，这是一种完美的线形扩展的场景。但是这不符合实际的业务场景，大多数的实际业务都会有很多不同维度之间的数据交互。TPC-C 测试标准也是对此认真考虑，所以对于事务操作数据的随机性规则提出了要求，最终要保证产生 10% 的“订单创建”事务和 15% 的“订单支付”事务要操作两个及以上的仓库。在 OceanBase 数据库内，这样就产生了跨机器的事务操作，而这必须使用两阶段提交协议来保证原子性。
OceanBase 会自动跟踪一个事务内所有 SQL 语句操作的数据，根据实际数据修改的位置自动确定两阶段提交的参与者，事务开始提交时，OceanBase 自动选择第一个参与者作为协调者，协调者会给所有参与者发送 Prepare 消息，每个参与者都需要写各自的 Redo Log 和 Prepare Log（也意味着每个参与者各自做自己的 Paxos 同步），等协调者确认所有参与者的 Redo Log 和 Prepare Log 完成后，然后再给所有参与者发送 Commit 消息，再等所有参与者的 Commit 工作完成。整个协议是在事务提交过程中自动完成，对用户完全透明。OceanBase 为每一个两阶段提交事务自动选择一个协调者，整个系统任何机器都可以分担协调者工作，所以 OceanBase 可以将事务处理能力进行线形扩展。
多版本并发控制保证事务的隔离性(Isolation)
TPC-C 标准里要求“订单创建”、“订单支付”、“订单配送”、“订单支付”事务之间都是串行化隔离级别（Serializable）。OceanBase 采用的方法是基于多版本的并发控制机制。事务提交时会申请一个事务的提交时间戳，事务内的修改以新的版本写入存储引擎，并且保证之前版本的数据不受影响。事务开始时会获取一个读取时间戳，整个事务内数据的读取操作只会看到基于读取时间戳的已提交数据。所以，事务的读取不会遇到脏数据、不可重复读数据以及幻读数据。同时，事务的修改会在修改的数据行上持有行锁，保证两个并发的修改相同行的事务会互斥。
OceanBase 的全局时间戳生成器也是由多副本组成，可以独立部署在三台机器上，也可以像这次 TPC-C 评测中一样部署在 root node 机器上，与 root node 共享资源。全局时间戳的三副本是一种极高可用的架构，任何一次时间戳的获取操作都至少在三台机器上的两台获得了确认，所以任意一台机器出现故障，获取时间戳的操作不会有一点影响。
按照 TPC-C 标准，OceanBase 准备了 9 种不同的场景测试有读-读、读-写冲突时事务的隔离性，最终都完美通过了审计员的审计。
一致性保证(Consistency)
在有了上述的事务能力后，OceanBase 可以完美的保证各种数据的一致性的约束。TPC-C 标准里提出了 12 种不同的一致性测试场景在各种测试运行前后对数据库内的数据进行一致性校验。因为 OceanBase 此次测试数据规模庞大，一致性校验的 SQL 需要核对大量的数据，所以一致性校验的挑战在于校验的 SQL 本身运行的效率。基于 OceanBase 的并行查询能力，发挥整个集群所有的计算资源，校验 SQL 的运行时间均缩短了几个数量级，很好的完成一致性功能的审计工作。
复制表
TPC-C 测试模型中有一张商品（ITEM）表，这张表的内容是测试所模拟的销售公司所有售卖的商品信息，包含了商品的名字、价格等信息。“订单创建”事务执行中需要请求这张表内的数据来确定订单的价格信息，如果商品表的数据只存放在一台机器上，那么所有机器上发生的“订单创建”事务都会请求包含商品表的机器，这台机器就会成为瓶颈。OceanBase 支持复制表功能，将商品表设置为复制表后，商品表的数据会自动复制到集群中的每一台机器上。TPC-C 标准不限制数据的副本数，但是不管数据的组织形式，标准里要求事务的 ACID 一定要保证。OceanBase 使用特殊的广播协议保证复制表的所有副本的 ACID 特性，当复制表发生修改时，所有的副本会同时修改。并且，当有机器出现故障时，复制表的逻辑会自动剔除无效的副本，保证数据修改过程中不会因为机器故障出现无谓的等待。复制表在很多业务场景中都有使用，例如很多业务中存储关键信息的字典表，还有金融业务中存储汇率信息的表。
总结
OceanBase 坚持在普通的PC服务器上实现高可靠、高可用、高性能、可扩展的数据库，实现了用廉价硬件和云计算的部署环境提供最关键的数据库服务的能力。后续，我们会持续优化事务处理的性能，丰富事务的各种功能特性，为用户提供更好用的数据库服务。
作者介绍：韩富晟，现任蚂蚁金服 OceanBase 团队资深技术专家，OceanBase 初创成员之一，目前负责 OceanBase 事务引擎以及性能优化相关的研发工作。
本文作者：韩富晟
阅读原文
本文为云栖社区原创内容，未经允许不得转载。