性能跃升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所一直秉承的理念。