阳振坤深度解析OceanBase如何支撑支付宝双十一14万/秒笔交易-CSDN博客

谈到2015年天猫双11，912.17亿之外，大家往往记住的第二个数字是“1秒钟14万笔订单（刷新交易峰值世界记录）”。可惜对于技术实践所涉及的内容并不多。而搜索引擎中居于首位的还是知乎上关于2014年双11的一个讨论贴。

直到看到蚂蚁金服平台产品技术部基础数据部高级研究员阳振坤内部培训程：“OceanBase如何支撑支付宝双十一每秒十四万笔交易”，才对其背后的技术有了更多了解，同时对困扰许久的几个问题有了明确的解答。特别整理并分享出来。【文章已经得到阳老师的确认】

OceanBase不需要高可靠服务器和高端存储

OceanBase是关系型数据库，包含内核+OceanBase云平台（OCP）。而与传统关系型数据库相比，最大的不同是OceanBase是分布式的，支持水平线性扩展；基于PC服务器，无高可靠服务器，无高端存储（共享存储）。这和一些传统数据库背后一定要有共享存储是完全不同的。

现在OceanBase已经在支付宝、淘宝、天猫、一淘等多处使用。2014年双11交易中，只承担了10%流量，但今年双11中已经承担国内交易100%流量，国际交易100%流量，会员50%流量，支付充值50%流量等。

要知道，交易多套核心系统在OceanBase之前都是某商业数据库的，这也是业内广为流传的故事了。（技术细节可以参考《揭秘阿里服务互联网金融的关系数据库——OceanBase》）

2015年双11：
00:05:01：交易创建达到峰值14万笔/秒；
00:09:02：支付达到峰值8.59万笔/秒。

如果对这组数字无感，做个对比。Visa支付峰值是1.4万笔/秒（实验室测试是5.6万笔/秒）；MasterCard实验室测试是4万笔/秒。

有个一直困扰业内的问题：支付为何比交易要低？交易创建时，支付宝内部就可以实现。但要支付，涉及扣款，来源可以是花呗、余额宝和银行渠道，如信用卡和储蓄卡等，尤其银行渠道方面，其中都需要交互时间。一般来说，传统银行峰值多是在几千笔每秒。

这样的交易笔数在全球都是遥遥领先的。

当然，过程并非完全一帆风顺。比如去年曾经一块硬盘坏了，还好有容错，自身屏蔽了。今年没有硬盘故障，但有一个业务在压测环节没有发现，其查询量极大，且随着交易量增加而增加，每整分钟都会有查询产生，指向应该是备库，但实际是却是指向了主库。所以技术工程师发现每个整分钟都有交易抖动。最后采用了紧急变更的方法，将查询调到备库才得以解决。

数据库有很多技术重点。但有几点很重要，第一、第一、第一（重要的事情重复3遍）是可靠性。

先分析下传统方式，如传统数据库+高端共享存储，或冗余方式来实现。服务器也要高可靠。所以要实现5个9，软件、存储、服务器都很贵，服务也贵。而为了避免不可控因素，传统数据库形成了主备镜像。有三种方式：Maximize Protection，Maximize Performance、Maximize Availability，各有利弊。事实上，传统方式的可靠性很好，但在可扩展能力、成本（性价比）上才是制约。

相比之下，PC服务器集群，性价比高、水平扩展、易于采购和维护等，亮点多多。但制约只有一个，稳定性可用性不如高端服务器和高可靠存储。如果说高端服务器和存储可以做到5个9，那x86 PC服务器能做到3个9就不错了。所以机器不可靠，但系统就必须要可靠。这就是云计算的思路。同一数据存在多地。那么每个事务到达超过半数库时，少数库故障肯定就不会影响业务。

再引用一段博客内容的分析：

为此，OceanBase引入了Paxos协议，每一笔事务，主库执行完成后，要同步到半数以上库(包括主库自身)，例如3个库中的2个库，或者5个库中的3个库，事务才成功。这样，少数库(例如3个库中的1个库，或者5个库中的2个库)异常后业务并不受影响

那么有个问题：存了3份数据，是否只利用了三分之一的服务器？不是的，因为磁盘空间会有浪费，但是比共享存储要少的多。而且备份服务器也是其他系统的主服务器。要实现高可靠性，这一点浪费是必须的。

版本升级是数据库故障最大发生处

传统数据库的版本升级是最要注意的。一些大的故障多是出于此。业内有些做法是先升级备库，升级完成后，将主库迁移过来。但这一过程也要打问号。因为版本升级造成数据库问题，业内屡见不鲜。比如2013年某国有大商业银行因为数据库版本升级，造成业务停顿近1小时。再如2014年某国的签证数据库罢工（后查明是因为一个小补丁），20万份签证被拖延几星期。

相对这些传统数据库，几年才出一个版本，内核开发测试团队就有千人，只有觉得很可靠时，才会对外发布。但互联网节奏不容许如此，所以OceanBase面临的挑战更大。为了快速响应业务需求，OceanBase最初一个星期会发几个版本，现在则是1-2周发布一个版本。

OceanBase开发之初就开始思考这个问题。即使到现在，从1个测试人员到现在十几，OceanBase的测试团队连人家零头都不算。问题始终存在，办法总要想去来——灰度升级。

详细分析下：

与传统数据库相比，OceanBase的另外一个关键特征是软件版本的灰度升级。主备方式的传统数据库是“单活”的，只有主库可执行写事务，尽管维护升级时可以先操作备库，操作完成后备库变成主库并且接受用户访问是一步到位的，如果新版本有问题，则业务受到影响。而OceanBase则是“多活”设计，即多个库（3个，5个等）每个都可以有部分读写流量，升级时先把要升级的库的读写流量切走，升级后先进行数据对比，正常后逐步引入读写流量(白名单，1%，5%，10%......)，一切正常并运行一段时间后再升级其他的库。

比如出现新版本异常，赶快将新版本上的流量切走。对业务的影响是可控的。除此以外，每个事务带64位校验码，每个表及每个列带64位校验码，都来保证事务和表列的正确性。

OceanBase与传统数据库的技术区别

有三个问题值得关注。

为什么传统数据库难以灰度升级？因为传统数据库备库就是备库，不是Active的，只有出现问题或者升级替换时才会变成主库。而OceanBase每个库都是Active。
为什么传统数据库不可以用PC服务器代替高端服务器和存储？一方面是一台普通PC服务器不能撑住传统数据库，且出现故障几率大，另一方面是软件机制需要做很大更新，而传统数据库是将这些硬件可靠性通过高端产品来实现，而专心做SQL优化、IO优化、排序优化等。
为何数十年来，数据库方面很少有能够挑战某商业数据库的统治地位？因为数据库事务（ACID）实现非常复杂，业务对数据库的稳定性要求极高。也因为磁盘IO瓶颈严重制约着数据库的性能，用同样的技术实现途径，其他厂商很难超越它，而全内存数据库成本太高。

那么OceanBase的切入点是在哪里？

随着发展，现在的数据库存储的数据量越来越大，多是以TB来统计。但一天修改量并不大，增删改（修改）只是很少的一部分，比如全国人口数据库、账务库、交易库都是这样。基于这样的原则，OceanBase用磁盘存储数据库，但用内存数据库来存储修改数据，没有额外成本。还消除了随机写磁盘，批量来写入，非常适合SSD（固态盘）【进一步解释下，普通磁盘最怕随机读，但SSD很适合。利用这一特性，OceanBase每天一次真正同步修改到磁盘上】。修改增量融合也采用了多库异步的方式，避免了对业务的影响。要知道，以块为单位来设计的数据库是很难做到这一点的。

现在，OceanBase已经广泛使用在阿里集团的金融领域，如交易、支付、清算等。今年双11还成功承担了开篇时提到的任务。

要注意的是OceanBase 1.0还消除了UpdateServer单点，且正从语义+协议方面完全兼容MySQL，DBA可以将MySQL完全替换成OceanBase，但应用层是完全感知不到的。对业务完全透明，这样至少能将数据库服务器减少一半。