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

本文转载自公众号蚂蚁金服科技（ID：Ant-Techfin）。

原文链接：

https://mp.weixin.qq.com/s/Asx6lP_v_b2tCD6rvvQN1A