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事务引擎以及性能优化相关的研发工作。