10 月 23 - 25 日,QCon 上海站即将召开,现在购票,享9折优惠 了解详情
写点什么

蚂蚁双 11 的这群筑梦师

  • 2019-08-29
  • 本文字数:3311 字

    阅读完需:约 11 分钟

蚂蚁双11的这群筑梦师

小蚂蚁说:

你和五年前最大的区别是什么?对 OceanBase 来说,是每年双 11 突破前一年的记录。

从支付宝切给 OceanBase 1%的流量到 100%的流量,甚至支付宝把包括账务在内的所有核心数据链,全部搬到 OceanBase 上;从 2014 年的 285 万笔/分钟的交易峰值和 571 亿元的交易额到 2018 年的 2135 亿元创纪录的成交额,五年时间,每年都在发生奇迹。而创造这些记录的就是支撑双 11 的核心数据库 OceanBase 以及蚂蚁双 11 的这群筑梦师。


对于蚂蚁而言,每年的双 11 是既令人敬畏,又令人兴奋的。


敬畏源自对技术的执着。面对这样一场几亿人的购物狂欢,不能也不允许有一点点的差池。这种敬畏对于外人而言甚至有点“着了魔”——技术人员拜关公、烧香、穿战袍和红内裤,甚至预案的精细粒度达到「如果当晚茶杯在电脑上打翻了怎么办」这个话题。


兴奋是为了什么?


兴奋来自于未知。每年的双 11 对于蚂蚁金服,对于 OceanBase 来说就是一个超级工程,而下一年的双 11 又会突破前一年的纪录。永远不知道边界在哪里,但是一旦设定了方向就会不顾一切的往前冲。


严格来说,OceanBase 真正经历了五年的双 11。

2014 年

2013 年 5 月,支付宝下线了最后一台 IBM 小型机,完成了去 IOE 进程中的一次重要尝试。最重要的 O 如何去掉,又成为了摆在蚂蚁金服团队面前的一座大山。


2014 年,阳振坤(OceanBase 团队负责人)回忆道,当时大家在会议室里讨论支付宝交易库的上线,墙壁都快被吵破了,但是别人就是不愿意上 OB。


他们原来的交易、支付系统全都在 Oracle 上,当时的 Oracle 无论是在稳定性、可靠性还是性能方面,肯定比 OceanBase 要好得多。



双 11 作战室里的鲁肃


最后,在程立(花名鲁肃,蚂蚁金服 CTO)的力挺下决定切给 OceanBase 1%的流量试试。因为那几年业务发展的太快,当时 Oracle 的共享存储已经扛不住这个流量,按照当时的业务流量去做压测的时候,几分钟就要坏一块盘。


最后发现,把业务切掉 10%,才能勉强扛得住。所以最后决定把 10%的流量切到了 OceanBase 上。



2014 年双 11 的零时之后,出现了 285 万笔/分钟的交易峰值,这个数值是 2013 年峰值的 3 倍多。最后 2014 年的天猫双 11 交易额达到 571 亿元,OceanBase 0.5 版本成功应用于支付宝核心交易系统。


OceanBase 的老同学说,当时的第一反应是有点感动,有点欣慰,觉得我们真的撑住了!那一年,OceanBase 成功扛住了 10%的流量,顺利通过了交易洪峰的考验。

2015 年

2015 年天猫双十一的交易额达到了 912.17 亿元。


00:05:01:交易创建达到峰值 14 万笔/秒;


00:09:02:支付达到峰值 8.59 万笔/秒。



在当年,Visa 的支付峰值是 1.4 万笔/秒(实验室测试是 5.6 万笔/秒);MasterCard 实验室测试是 4 万笔/秒。这个数字已经让世界瞩目了。


2014 年,OceanBase 在双 11 算是一次牛刀小试,支撑了 10%的交易创建流量。在 2015 年的双 11,OceanBase 真正挑起了大梁。蚂蚁交易创建 100%切流到 OB 上,核心线的会员、充值、支付也都 50%切流到 OB,说是扛起来蚂蚁核心应用的半壁江山,一点也不为过。


从 10%到 100%,不仅仅是数字上的变化,其内部蕴含着性能、稳定性、可运维性、高可用等一系列的挑战。


当年的 DBA 热情洋溢地写道:


“如果缺少了‘一干到底’的精神,我们将很难在每一个细节上都做到完美。在双 11 这样的极端场景下,任何一个细节的疏漏,都很可能导致整个系统出现难以估量的损失。最终,OceanBase 经受住了双 11 的极致考验,14 万笔每秒的支付宝交易创建峰值(全部跑在 OB 数据库上)就证明了一切。”

2016 年

2016 年双 11 的成绩让马老师喜笑颜开。



“剁手党”们仅用 6 分 58 秒就让天猫双 11 的交易额破 100 亿元,2016 年天猫双 11 最终交易额突破 1207 亿元。



零点 9 分 39 秒,蚂蚁金服 CEO 井贤栋宣布,2016 年双 11 诞生了支付峰值的世界新纪录——12 万笔/秒,是 2015 年的 1.4 倍。


令人惊讶的是,如此庞大的交易量,系统不仅没出现大面积崩溃,而且还很稳。用当年也是现在 OceanBase 的 DBA 孔德生(花名沈炼)的话来说,“曲线 ‘丝般顺滑’,过程 ‘云淡风轻’ 。”


2016 年的双 11,OceanBase 1.0 版本承担了会员,交易,支付,红包,国际交易,花呗支付,账务前置,花呗账务,账务明细,会计,计费等系统的流量,支撑起了 2016 年 12 万笔/秒的支付峰值。


OceanBase 1.0 版本当时还是一个刚刚发布不久的数据库,从稳定性到性能几乎与业务改造同步,可想而之对于当年的 DBA 同学,业务同学和 OceanBase 团队来说是多么巨大的挑战。


而事实上,为了这个结果 OceanBase 团队已经踏踏实实积淀了 2 年时间。从 2014 年到 2016 年,整整两年的时间,整个团队中的 40 多个人,全部投在 OceanBase 1.0 版本的开发上。整整两年,这 40 多个人只做了这么一件事。

2017 年


2017 年 11 月 11 日凌晨,天猫双 11 全球狂欢节刚开场 5 分 22 秒,新的支付峰值诞生:25.6 万笔/秒,比去年增长超 1.1 倍,再次刷新全球纪录。同时诞生的还有数据库处理峰值,4200 万次/秒。



2017 年也是支付宝首次公布数据库处理峰值。4200 万次/秒的意思是,在支付峰值产生的那一秒里,OceanBase 平稳处理了 4200 万次请求数,这也再次直接应证了中国自主研发的数据库 OceanBase 已经跃升至全球数据库的第一梯队。


胡喜(花名阿玺,蚂蚁金服集团副 CTO、副总裁、首席架构师)介绍道,支付宝之所以在 2017 年首次公布“数据库处理峰值”,是因为 2017 年的双 11,支付宝首次把包括账务库在内的所有核心数据链,全部搬到了 OceanBase 上。


“对于用户来说,一笔支付就是一笔支付,对于数据库来说,一笔支付则是数个处理请求的集合。”胡喜介绍,用户进行支付时,钱可能从借记卡转出,从花呗借出、还有 10 块钱由优惠券出、分期付款……这些都是一个个独立的处理请求,需要数据库进行处理。在支付高峰,能否支撑得住海量级的处理并发量,对 OceanBase 来说是一个巨大的考验,而此次 4200 万次/秒的处理峰值充分说明,OceanBase 再一次经受住了考验。


2017 年的双 11,OceanBase 还有一个技术突破,是实现了“离在线混合部署”。它最核心的优势是,能够在双 11 支付峰值来临前,借调“离线机房”的闲置计算资源,并在峰值回落后再“还”回去。凭借这一技术创新,为 2017 年的双 11 支付保障节省了 2000 多台服务器。

2018 年

2018 年的双 11,仿佛真实的还在眼前。天猫双 11 最终以 2135 亿元创纪录成交额收官,支付宝系统在这场“商业奥运会”中再次经受住了考验。



胡喜透露,整体系统稳定、顺滑地度过刚刚过去的这 24 小时,离不开核心技术的全面开放,这其中当然包括了蚂蚁金服分布式数据库 OceanBase。




胡喜强调,支付宝已经将支撑双 11 自主研发的核心技术 100%开放出来,包括三地五中心多活架构 、分布式数据库 OceanBase、分布式架构 SOFAStack、生物识别平台 ZOLOZ、蚂蚁区块链 、智能风控引擎 AlphaRisk 等。


OceanBase 2.0 版本就全面支撑了 2018 年双 11 支付宝的核心链路。该版本性能比去年提升了 50%,这样交易不用临时扩容,真正实现了“零成本”支撑大促。


OceanBase 2.0 版本的设计可支撑百万支付峰值甚至无上限。此外,在完全兼容 MySQL 后,OceanBase 2.0 版本加强了对 Oracle 数据库的兼容。OceanBase 在性价比方面更是精雕细琢,使得在 OLTP 场景的实际应用中,OceanBase 2.0 版本相对于 1.4 版本,性能提升了 50%以上,存储下降 30%。

筑梦师?信仰者?

写到这里,突然想起《盗梦空间》里的一句话:


一个简单的念头可以创造一座城市,也可以改变整个世界。



我在想要怎么定义这群人,可以称呼他们为筑梦师,将所有最美好的最复杂的理想世界通过自己的“念头”筑造成现实。


倒不如说他们是自己技术理想的信仰者,即便在 OceanBase 即将解散的那些年,阳振坤还是会坚定如一的说,「OceanBase 以后是要取代 IOE 的」。


这种自信源自于对一件事极致的、不掺一丝怀疑的信念。


即便是最艰难的时刻,这种信仰还是扎扎实实的刻在 OB 人的心上,因为他们相信:先活下来,只要不离场,就还有希望。


当然这句话还有下半句——只要有希望,就总有机会实现。


本文转载自公众号蚂蚁金服科技(ID:Ant-Techfin)。


原文链接:


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


2019-08-29 20:012306

评论

发布
暂无评论
发现更多内容

价值几十万的 TiDB优化

TiDB 社区干货传送门

实践案例

【SOP 系列】TiDB 使用 SOP 最全合集

TiDB 社区干货传送门

TiDB 底层架构

TiDB升级5.0.2有惊喜

TiDB 社区干货传送门

版本测评

排序算法总结

乌龟哥哥

7月月更

PD 关于ID分配的源码分析

TiDB 社区干货传送门

TiDB 底层架构

TiFlink: 使用 TiKV 和 Flink 实现强一致的物化视图

TiDB 社区干货传送门

实践案例 TiDB 底层架构

Tidb灾难恢复演练-多副本丢失

TiDB 社区干货传送门

故障排查/诊断

TiDB 记录日志原理解读

TiDB 社区干货传送门

TiDB 底层架构

记一次TiDB优化

TiDB 社区干货传送门

性能调优

TIDB 入门运维基础视频教程(一)-- 快速体验

TiDB 社区干货传送门

安装 & 部署

TiDB+FLINK 实时计算

TiDB 社区干货传送门

实践案例

悲观事务加锁验证

TiDB 社区干货传送门

管理与运维

SpringBoot核心应用第一弹

Java学术趴

7月月更

前端食堂技术周刊第 44 期:Bun、Vue.js 挑战、React 状态管理的新浪潮、Can I DevTools、函数式编程

童欧巴

Vue React Bun

从一个简单的Delete删数据场景谈TiDB数据库开发规范的重要性

TiDB 社区干货传送门

故障排查/诊断

TSO 时间戳转换为自然时间

TiDB 社区干货传送门

实践案例

DELETE Statement,懂你不容易

TiDB 社区干货传送门

TiDB 底层架构

Placement Rules 原理

TiDB 社区干货传送门

TiDB 底层架构

TiDB 目录结构分析

TiDB 社区干货传送门

实践案例

当大数据架构遇上 TiDB

TiDB 社区干货传送门

实践案例

【TiDB 最佳实践系列】如何高效利用 Grafana 监控分析 TiDB 指标?

TiDB 社区干货传送门

监控

一个联合索引使用问题以及优化方案

TiDB 社区干货传送门

管理与运维 故障排查/诊断

TiDB 4.0 新特性也太爽了吧

TiDB 社区干货传送门

版本测评

TiDB GC 之原理浅析

TiDB 社区干货传送门

TiDB 底层架构

TiDB 在网易游戏的应用实践

TiDB 社区干货传送门

实践案例

一条 like 条件的慢 SQL 语句优化

TiDB 社区干货传送门

管理与运维

TiDB 5.1 发版,打造更流畅的企业级数据库体验

TiDB 社区干货传送门

新版本/特性发布

PD 关于tso 分配源代码分析

TiDB 社区干货传送门

TiDB 底层架构

TiDB 赋权问题

TiDB 社区干货传送门

故障排查/诊断

Spring&SpringBoot 源码笔记整理 |Bean 的加载流程一

自由

Spring5源码解析 7月月更

TiDB系统调参实战经验

TiDB 社区干货传送门

性能调优 实践案例

蚂蚁双11的这群筑梦师_文化 & 方法_荔子_InfoQ精选文章