你“剁手”的时候，支付宝在干嘛？
支付宝是目前使用率最高的支付方式之一，正值“双十一”之际，对于数亿人产生的每秒数万笔支付订单背后，是什么力量在保障交易系统的稳定性与交易过程的流畅性？
支付宝背后的技术力量，是连续两年在TPC-C测试中保持世界第一，并创造世界记录的数据库系统——OceanBase，已经在天猫“双十一”支付场景中稳定支撑了7年之久。那么，在每秒数万笔交易背后，作为数据处理核心系统的数据库提供了哪些关键能力，来保障狂欢者们“剁手”的速度？
近日，CSDN与OceanBase管理团队进行了一场对话，为大家揭开上述问题。
关键能力一：无损容灾与持续稳定运行
2014年的“双十一”，OceanBase第一次真正亮相，由于Oracle容量不足，无法应对业务高峰，支付宝团队考虑将万分之一的流量切换到OceanBase，结果出人意料，原本不被看好的OceanBase，顶住了支付宝交易10%的流量。自此，支付宝开始了三年的业务迁移之路，将所有在Oracle系统中的业务，包括交易、支付、支付工具（花呗、借呗）、账目、会员等业务都迁移至OceanBase。
为什么支付宝的核心业务最后都交给了OceanBase？主要有以下三点原因。
第一，无损容灾。据OceanBase CTO杨传辉介绍，“OceanBase做到了无损容灾，当服务器发生故障的时候，OceanBase可以做到不丢失任何一条数据”。其中的关键在于 Paxos协议，使OceanBase实现了机器级、机房级、城市级的无损容灾。但是，对数据及其敏感金融业务，需要商业数据库得到充分验证后才敢相信它真的不会丢数据，“你先证明给我看！”这个问题就雷同于“怎么证明我妈是我妈”，很难验证。最后还是蚂蚁集团CTO出面，愿意相信OceanBase的技术及其团队，又因为OceanBase是集团战略的一部分，使之顺利在“双十一”的支付宝交易业务中落地。
既然OceanBase搞定了交易，那也可以搞定支付吧？这是2015-2017年整个支付宝技术团队对OceanBase的期望，从不被看好到“你一定行”，大家的态度发生了180度大转弯。因此，将Oracle系统中的业务，全部迁移到了OceanBase。OceanBase顺势做了技术升级，将传统“两地三中心”式的异地容灾方案，升级为“三地五中心”。对于前者，如果故障真的发生，由于异地数据不一致，备库担心数据泄露而无法决策操作，只能等主库恢复，做不到真正的“稳定可靠”。升级后，用多个系统，多副本的系统来做隔离，形成了一套既保证业务连续性，又不损耗较高成本的核心方案，支撑业务快速发展。
第二，数据正确性。这也是OceanBase多年来在“双十一”以及其它大促活动中呈现的核心能力。保证数据库的“稳定可靠”，最难的是做出一套数据完全正确的系统，OceanBase怎么解决这个难题呢？与其他数据库系统不一样的是，OceanBase在早期就应用到了核心场景中，因此，其将数据库内化进系统内核中，做数据的实时校验，系统一旦发生错误或故障，就会非常快速地被发现，保障数据正确。
第三，持续稳定运行无异常。OceanBase曾在2019年参加TPC-C测试（TPC-C是全球最具公信力的联机交易处理数据库的功能与性能结合的测试标准。是商业数据库想要证明自身实力的一个硬性门槛），以6088万（60,880,800）的在线事务处理性能创造了世界纪录，一年后以7.07亿（707,351,007）的成绩再创记录。这看起来只是一串数字，但该数据背后，意味着仅一张表格的数据支持量就超过了20万亿，同时还要保持数据的一致性。另外，TPC-C 要求被测数据库能够以平稳的性能至少持续运行8小时，其中性能采集时段（不少于2小时）内的性能累积波动不得超过2%，OceanBase的成绩是持续运行8小时，抖动小于0.5%。这为“双十一”等极端应用场景提供了稳定保障，得以让用户在面对机器故障、磁盘故障、网络故障时还能毫无感知，愉快地“买买买”。
关键能力二：弹性扩缩容
高并发场景不仅需要极致的容量，还需要具备弹性扩缩容的能力。对于容量，分布式数据库天然支持无限扩展服务器，这是OceanBase在业务中的优势。在“双十一”期间，他们会快速增加服务器，30分钟实现近5000台机器，并做性能优化和降本增效，锻炼容量能力，提升单机性能。据OceanBase CEO杨冰透露，每一年OceanBase都会设立一个项目，根据上一年“双十一”的需求来专门提升性能和优化成本，比如相比去年，今年读写提升了61%，而成本只有MySQL的三分之一左右。
对于数据库本身的弹性扩展能力，杨冰谈到支付宝的“百万级副本的能力”，即每秒最高峰值为一百万笔支付，这在数据库系统中，可能接近亿级QPS（Queries-per-second，查询率），“双十一”期间，每秒都会产生数万笔支付，对此，OceanBase通过两层弹性技术来支撑，第一层是中间件的分库分表，第二层是OceanBase的分区表格。先通过分库分表将数据分成一百份，再通过分区表格将这一百份分别拆分出一百份，共拆分出一万份，使得每一份都至少能在一台机器上，以此做自动的弹性。
通常，有分库分表就足够了，OceanBase为什么要再做一层？分库分表的好处在于对数据库依赖比较低，但问题是基于分成的一百份，想再拆分为一千份、一万份时很难，所以每用一次就需要上百人拆库，做技术攻坚。这才有了OceanBase的分区表，自动扩容，不再需要担心容量的问题，且对整个业务几乎没有影响。
此外，弹性能力还指在云上快速扩容缩容的技术。如今，普通机房的机器已经不能满足大促活动的数据处理了，尤其是“双十一”当天的容量比平常高出几十倍，这时，需要借助云计算的能力，把业务数据、服务快速地部署到云上。“双十一”结束后再迅速撤下来，因为在云上多待一小时就多花一小时的钱。这个过程就是快速弹上和弹下。了解数据库的人知道，这可是件麻烦事。上万台服务器拷贝上云，需要并行执行，过程中涉及近50万次变更操作，包括跑数据，加数据、准备切换等，所有变更操作由系统执行，且不能对业务有任何影响。
关键能力三：智能运维与实时交易分析
“双十一”期间会遇到很多问题，比如11月11号凌晨交易峰值之下可能造成服务器卡顿、故障等，那么如何才能保证数亿用户持续流畅的支付体验呢？上文提到，为了保证容量与弹性，OceanBase的服务器非常多，CPU达数百万级，怎么确保全部稳定运行？以及11月11号当天近50万次的服务器变更操作，如何更有效地执行？这就涉及到效能的问题。
过去7年，OceanBase把支撑“双十一”交易和支付基本搞定了，但如何做创新业务还有很长的距离要走。因此，在运维方面，OceanBase决定结合AI技术，将越来越多的运维工作交给AI，让其智能化、自动化诊断问题，并在发现问题后做出相应决策，以此提升DBA效能。杨传辉坦言，最理想的状态是“双十一”不需要人来值班，
除智能运维外，OceanBase也坚定提供实时交易分析能力。OceanBase最初是OLTP型数据库，随着业务场景对实时交易和智能分析的需求增大，其开始将HTAP作为核心能力之一。举个例子，“双十一”期间需要分析商家的交易数据，供商家了解交易情况以及进一步调整商品信息。此前，商品交易完成后，数据会汇集到离线数仓进行分析，至少几小时后才能出分析结果。而在“双十一”这样的大促场景中，商家迫切希望尽快查询到交易数据，快速做出下一步销售响应。当OceanBase具备HTAP的联机事务实时交易分析能力后，一套系统既可以交易又支持实时分析，商家能够在交易完成立即查询到商品卖的怎么样，相关类目商品卖得怎么样，做出进一步的促销战略。
关键能力四：一体化架构
上述三项关键能力是OceanBase过去7年为支撑“双十一”而运用的技术支撑，未来，随着AI、IoT、云计算等技术的发展，“双十一”等大促场景一定会出现新的需求，对此，OceanBase团队提出了新的应对理念：一体化架构。可以简单将其理解为三项融合，即集中式兼容分布式、融合OLAP与OLTP、结合本地与多云部署。
具体而言，一体化架构的底层为原生分布式架构，对外能够与经典数据库对标，且兼容Oracle、MySQL等数据库系统。这就同时具备分布式与集中式两种系统的优势，也就是说，既具备优秀的单机性能，又具备高可用、高扩展、低成本等特点。
之所以坚持原生分布式架构，是因为OceanBase团队认为原生分布式架构是未来核心系统的首选，同时“将复杂留给数据库，把简单留给客户”，比如容量不足的问题、系统故障的问题等都由数据库解决，而不是中间件、OLTP和用户去用对。而能够代表未来的原生分布式架构一定既能做边缘场景也能做核心场景，只有在核心场景取得突破才能真正代表未来，因此，OceanBase也在持续优化核心场景（如“双十一”）的技术能力，如提性能、降延迟、强化兼容等。
此外，OceanBase开源内核引擎，也是技术战略中的关键一步。内核引擎是开源了，但是上面的一些增值服务和工具没有开源，需要产学研各界专家、合作商、用户协同共建。并且，多云部署已经成为一种可预见的趋势，开源后可以将数据库资源部署到多云、公有云，既能在未来为更多云上企业提供服务，又能实现商业变现。
结语
从今年的“双十一”狂欢夜顺滑的支付状态来看，OceanBase又一次打赢了这场技术战役，回首12年的“双十一”历程，用户从PC端到移动端、从万民狂欢到全民狂欢、参与了一次次的消费升级，也见证了“双十一”背后的技术发展。技术支持团队在逐年暴增的数据浪潮下，一次次完成保卫系统、守护用户的艰巨任务，真正以技术力量支撑商业史不断创造新纪录。