性能跃升50%！解密自主研发的金融级分布式关系数据库OceanBase 2.0

摘要：小蚂蚁说相信大家对蚂蚁金服自主研发的金融级分布式关系数据库的故事不再陌生了。文末有彩蛋在普通硬件上提供极限性能的数据库服务是完全自主研发的金融级分布式关系数据库，从架构上可以通过扩展机器来解决集群服务能力的扩展需求。

小蚂蚁说：
相信大家对蚂蚁金服自主研发的金融级分布式关系数据库OceanBase的故事不再陌生了。在刚刚过去的2018年天猫双11中，成交额2135亿再次创造了新纪录，而支撑今年双11的支付宝核心链路就是OceanBase
2.0版本。
本文小蚂蚁将为大家详述OceanBase如何在去年同样机器数量的情况下，来支撑今年双11的流量洪峰，一起来学习一下吧~

本文作者为蚂蚁金服OceanBase团队资深技术专家颜然，他也是OceanBase初创成员之一，目前负责事务引擎以及性能优化方面的研发工作。（文末有彩蛋）

OceanBase：在普通硬件上提供极限性能的数据库服务

OceanBase是完全自主研发的金融级分布式关系数据库，从架构上可以通过扩展机器来解决集群服务能力的扩展需求。

OceanBase采用多副本复制的方案解决了可靠性和可用性的需求，而且构建在普通PC服务器上，不依赖于高端引擎。

我们的目标是在普通硬件上提供极限性能的数据库服务。那么，OceanBase的存储引擎有什么特点呢？

OceanBase的存储引擎类似于LSMTree，所有新增的修改都会先记录在Memtable中，这些数据的变更并不会实时写到磁盘上，而会在后台定期写到硬盘上。

不管是磁盘还是SSD，当有大量写入的时候，它的读取性能都会受到很大影响。从一开始OceanBase的架构就是为了适应这种硬件的特性，所以没有随机写的操作，对于SSD和磁盘都很友好，可以将硬盘的吞吐量优势发挥出来，把硬件资源最好的性能压榨出来。

OceanBase从0.x版本到1.x版本，再到现在的2.0版本，一直在推动的一件事就是把硬件的性能做到极致，希望在同样的硬件条件下能给业务带来更多性能的空间。OceanBase的目标一直是有极致性能并且性价比最好的数据库。

OceanBase的性能目标：极致压榨硬件性能

从用户使用角度来看，数据库有两个重要的指标，延迟（Latency）和吞吐量（Throughput）。这是两个非常不一样的指标。

根据排队论模型，这两者之间的关系如上图所示：随着吞吐量增加，延迟近似指数倍增长。

当整体系统的性能不是特别高的时候，可以保持延迟的稳定性。当系统性能压力很高的情况下，延迟会增加，我们要做的事情就是要在一个合理的延迟情况下，让吞吐量可以尽可能大。换句话说，其实就是把一个请求要做的事情尽可能的减少，然后让单位时间内能做的请求尽可能的多。性能优化的最终目标就是在延迟可以接受的场景下，尽可能提高系统的吞吐量。

性能优化工作

在刚刚过去的2018年天猫双11中，成交额2135亿再次创造了新纪录。那么在蚂蚁金服/支付宝这样的场景下，支付的压力会全部落在OceanBase 2.0版本上。在2.0版本里我们做了一个很重要的事情来进一步压榨硬件的性能——也就是在去年同样机器数量的情况下，来支撑今年的流量洪峰。

在同样的硬件环境，同样的机器规模数这些条件下，通过升级的服务器版本以及服务器的部署方式，来提供今年双11在0:00:00洪峰到来时的抗压能力。 双11的支付压力是典型的OLTP模型，有大量的增删改查操作。OceanBase的存储模型决定了操作主要在内存中进行，所以在满负荷运转下CPU是主要瓶颈。

CPU的资源如何压榨到极致，其实主要包含两方面的工作：

一是优化语句执行消耗指令数（Instructions /SQL），即每个请求需要执行的指令数，指令越少越好；
二是优化系统执行指令的效率（Cycles /Instruction），可以用CPI（Cyclesper Instruction）表示。

系统性能由每一行代码决定

任何一段代码都可能导致bug，任何一行代码也都有性能优化的空间。针对不同的场景，我们需要深入到每行代码里去看可以做什么样的优化。

OceanBase 2.0版本进行了深度的优化获得了很好的性能提升。上图所列的只是其中一部分优化工作。性能优化是一个事无巨细的工作，有点类似于测试工作，本质上每一行代码都会影响系统的性能。

优化CPU开销

Commit异步化

在OceanBase已有的模型里，网络模块有多带带的线程池负责和客户端通信，接受用户请求和返回请求结果。接收到的请求会发在任务队列中由工作线程处理。

相比较于每一个用户的连接使用一个独立的线程服务的模型，OceanBase的模型可以大大减少上下文切换的次数。

对于SQL语句的执行，这已经是一个很好的模型了。但是对于事务的提交操作，需要将日志在本地持久化和发送到其他副本持久化，提交操作又会使得工作线程出现等待的情况。

Commit异步化是在事务提交日志后不再等待日志持久化，工作线程可以直接去队列中取下一个任务执行。等日志持久化完成后，通过回调的方式出发事务提交完成的操作和给用户发送请求的结果。

优化系统扩展性

扩展性问题

我们做了很多事情让系统少做无谓的事情，多做有用的事情，也就是增加CPU做有效工作的时间占比。

机器的CPU核数越来越多，从原来的几十个核和现在的一百多个核，在英特尔的PC Server上都是很常见的场景。系统在服务器上运行，多核CPU的扩展性是一个很重要的方面。这里以计数器场景举例，单个线程和多个线程一起操作同一个计数器，后者因为多个核之间竞争同一个内存单元，性能会下降几百倍。其实有时候人多不一定力量大，人多也有可能导致大家一起抢赛道。

在系统中也大量存在类似的竞争场景，内存分配器是一个常见场景。多个线程在操作同一个memtable时，会从连续的内存块中分配内存，分配内存的操作就好似计数器的竞争。所以，要把memtable的内存分配操作做成分区的形式，减少多个核之间的竞争。

说到底性能优化其实就是在优化系统的各个细节，每个细节都要做到极致，最终性能才能压榨到最好的那个点，才能把硬件本身的性能发挥到最好。

性能无止境

我们可以看到，蓝色块代表的是OceanBase 1.4版本，也就是我们现在使用的主力版本，绿色块代表了OceanBase 2.0版本。A场景是下单场景，也就是点提交订单时的操作，B场景是支付场景，就是登到支付宝里去最终付款的场景。

最后结果是：在下单场景下，OceanBase 2.0版本比1.4版本的性能提升了63%，在支付场景下，提升了58%。

OceanBase的未来

未来OceanBase会加强面向全栈的优化，同时会对工作负载进行优化，也会有面向新硬件方面的优化工作。

OceanBase会持续进行性能优化的工作，目的是持续为用户提供具有最高极限性能以及最好性价比的产品。这是OceanBase所一直秉承的理念。