以为是青铜，没想到是王者！登顶TPC-C的OceanBase为双11做了啥？ 原创

2009年，蚂蚁金服OceanBase写下第一行代码；2019年，OceanBase刷新了甲骨文在TPC-C排行榜保持9年第一的记录。此时的OceanBase，代码已超百万行，支持着支付宝100%核心业务的运行，正在为不少银行、保险、证券机构赋能。

但回顾OceanBase的发展史，虽然身处自研核心领域，但研发之路却曾被冠以了诸多质疑，项目甚至险些“夭折”。由于MySQL就能满足淘宝大部分业务需求，而业务系统改造工作量之大也导致OceanBase数个月无法上线，在2014年之前，OceanBase一直被认为只是一个“青铜”。不仅5年时间里只更新到了0.5版本，没有固定的业务，最落魄的时候，甚至还面临着团队解散的境况。

2014年是OceanBase的关键年。在双11前的压测中，甲骨文数据库出现了10%的流量缺口，而就在临近这一“大考”的十来天里，OceanBase“临危受命”去弥补这10%的缺口——相当于支付宝平日流量的最高峰值。对于当时外表看起来甚至还只是个demo的OceanBase来说，这个任务虽然有点“赶鸭子上架”，却是一个“翻身”的好机会。

那个双11，OceanBase在短短不足两周的时间里把长达10毫秒的响应时间降低到了1毫秒一下，以零差错的优秀表现一战成名，自此成为每年双11核心支撑系统，向“王者”进发。

做OceanBase是因为业务需求

在今年的天猫双11狂欢日当天，OceanBase2.2以6100万次/秒的成绩再次刷新了数据库处理峰值记录，甚至超过了一个月前在TPC测试中的表现。

虽然同是关系型数据库，但和甲骨文的集中式数据库不同，OceanBase是面向高并发、大数据环境而生的分布式关系型数据库。基于完全的分布式架构设计和PAXOS协议，OceanBase的工作方式是把原来集中存储和处理的数据分散到不同的机器上，如此一来，系统的存储和计算能力就能通过增减机器而实现水平伸缩，支持大规模高并发的效果。

此外，为了进一步提升性能和降低延迟，在今年的双11中，OceanBase还通过中间件的优化，自动将多条SQL聚合成轻量级的存储过程，这个过程让原本需要数十次SQL网络交互的任务降低为单次网络交互，整体RT降低了20%。

在今年双11之后，蚂蚁金服高级研究员阳振坤与媒体分享了背后的蚂蚁金服技术。谈起研发这样一种分布式数据库的初衷时，他表示，要做数据库的研发首先要有业务需求，传统的数据库对于在线交易处理和在线分析处理虽然具有非常强的能力，但是随着互联网的发展，线上交易量和数据量出现了成百上千倍的增长，作为系统支撑的单个硬件难以支持这样的快速变化，因此，原来由同一关系数据库进行的OLTP和OLAP处理演变成了由数据库分库分表和数据仓库两个系统分别来做。

蚂蚁金服高级研究员 阳振坤

“这样的变化带来了很多不便。首先，最麻烦的是数据仓库与交易处理数据库的连接；其次，交易数据库分库分表在业务量浮动过程中不够灵活；其三，数据仓库数据冗余并且不是实时更新，这带来了很多问题。而这些问题就是促使分布式关系型数据库出现非常重要的原因。”阳振坤表示。

然而，据他所说，分布式系统的设计特点是把多台机器连在一起进行存储和计算，这往往会带来整体可靠性的指数级降低，因此，OceanBase在推出之初一直不被看好。“正因为存在这样一些质疑，才促使我们下决心全力参与TPC-C benchmark测试。”阳振坤说。

做TPC-C测试是为了消除质疑

阳振坤解释，要做TPC-C benchmark测试，第一步是要证明系统能够做交易处理，能够满足事务的ACID（原子性、一致性、隔离性、持久性），在这前提下才能进行下一步测试。而目前，除了OceanBase之外，分布式架构中能够满足数据库事务ACID的，已知的仅有Google的Spanner。这意味着，如果不能保证ACID，堆叠再多的硬件也无法通过TPC-C测试，更不用谈跑分。

那么，是如何在满足横向扩展需求前提下解决高可用问题的？

“一方面，基于PAXOS协议，OceanBase把原来的每一个物理节点换成了一个虚拟节点，这个虚拟节点背后有3到5个物理节点。借此，就解决了分布式事务的横向扩展问题。另一方面，对于高可用，我们的做法是增加一个备库，将主库事务同步到两个备库。也就是说，每一笔交易会至少在3个库中的2个库落地存储，从而降低机器故障的风险。这样一来，系统的高可用性就会大大提升。”阳振坤介绍。

在这方面，事实上TPC-C也不仅仅只是测试性能和性价比，在系统稳定性、高可用方面都有测试，除了满足性能，同时还需要连续八个小时稳定的持续的运行。对此，OceanBase更是做到了8小时的性能抖动<0.5%。这也说明，OceanBase在具备在大规模生产环境下长期平稳运行的能力，在稳定的前提下，又能够做到极高的性能。

所以说，OceanBase在TPC-C的测试中取得的成绩，更多代表了分布式架构的大趋势。虽然与甲骨文数据库在具体功能上还有不小差距，单机的平均性能也有距离，但是OceanBase最大的优势是可以用大量廉价的通用服务器达到昂贵高端硬件所能达到的极致性能以及更高的可用性。阳振坤强调：“我们做这个测试最大的价值其实就是想向外界证明，我们的分布式数据库既能做交易处理，也能做智能场景分析，不仅能实现无限扩展，同时还具有强大的可用性和可靠性。所以接下来，我们要做的就是把商业智能融入其中，向企业提供所需的交易处理和商业智能分析能力。”

迎战双11的更多“秘密武器”

正因为有了非常可靠的实力，在今年双11中，支付宝支付业务100%已经切换到OceanBase内置的Oracle兼容模式上，支持Oracle语法以及存储过程优化的同时，又兼具OceanBase的分布式能力，如分布式分区表、全局事务等，响应时间也更加平稳。据了解，双11之后，OceanBase2.2也将正式公开发布。

当然，要支持双11这样一次几乎代表着流量并发最高极限的“大战”，支付宝还有很多“秘密武器”。这些“武器”与OceanBase一样，在每年的双11中“身经百战”，并且已经一一从后台走到台前开始独当一面。

其中，针对金融行业的特殊需求而开发的金融级中间件SOFAMesh通过分时复用，今年已经将切换资源所需的系统重新配置和部署时间缩短到了3分40秒，并覆盖100%的蚂蚁金服核心支付链路，几十万容器，峰值千万QPS，平均RT（响应时间） 0.2ms，成为业界最大的 Service Mesh 集群；实时金融级分布式图数据库GeaBase凭借主链路上单集群规模突破万亿边，点边查询突破800万QPS，平均时延小于10ms，也成为支付宝核心链路上非常重要的一环；新落地的融合计算引擎，在今年双11跑在了蚂蚁金服关键决策链路上，减少了60%的机器资源使用，把端到端的延迟降到了毫秒级，在至少在三个场景中成功使用。

回看双11走过的11年，这样一个从电商大促演变成全民狂欢的节日，正在演绎着技术与商业的相互成就，成为阿里巴巴和蚂蚁金服诸多技术的“阅兵场”，将许多“不可思议，化成了寻常”。如蚂蚁金服资深技术专家赵尊奎所说：“过去，我们去挑战技术高峰，每年都很难，要很努力地跳一跳才可能够得到，虽然现在还是每年都很难，但是从心态上我们发生了很大转变，我们总有自信自己一定可以达到。”