AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

首次揭秘双 11 双 12 背后的云数据库技术!

  • 2022-01-25
  • 本文字数:3855 字

    阅读完需:约 13 分钟

首次揭秘双11双12背后的云数据库技术!

从 2009 年到 2021 年,从千万交易额到千亿交易额,双 11 已经开展了 12 年。如今,每年的双 11 以及一个月后的双 12,已经成为真正意义上的全民购物狂欢节。刚刚过去的 2021 年双 11,就有超过 8 亿消费者参与。


与攀升的交易额和参与人数相反,双 11 的主要阵地“淘宝 APP”、双 12 的主要阵地“天猫 APP”的崩溃情况逐年减少近无。在此基础上,淘宝及天猫还在不断吸收来自消费者的反馈,优化功能,比如在 2021 年开始支持购物车实时显示券后到手价、搜索已经购买过的订单……应用上大量的操作请求流转到技术后台,给数据库带来了不小的压力。


是什么样的数据库撑起了 2021 年的双 11 双 12 的稳定进行?《数据 Cool 谈》第三期,阿里巴巴大淘宝技术部双 12 队长朱成、阿里巴巴业务平台双 11 队长徐培德、阿里巴巴数据库双 11 队长陈锦赋与 InfoQ 主编王一鹏,一同揭秘了双 11 双 12 背后的数据库技术。

让热点秒杀真正意义上实现“拼手速”

秒杀作为电商中的常见业务场景,在淘宝上如今也是一个常态化的业务,比如每天晚上 8 点手机淘宝上抢茅台的活动。但是这种活动在早年间,其实并不容易稳定进行。当海量的数据瞬间涌入,对系统造成脉冲式的冲击,一下子就会把系统打挂。这个时候用户看到的就是页面挂了。淘宝开始考虑通过加入排队能力,解决系统秒挂的情况,但在用户侧会看到页面在转圈圈后显示抢购结果,体验感并不好。


在双 11 双 12,这种方式的弊端会被进一步放大。数据显示,在双 11 秒杀系统中,秒杀峰值交易数据每秒超过 50 万笔,是一个非常典型的电商秒杀场景。在 0 点那一刻下单爆发后,随着第一波下单的完成,消费者很快开始重新逛淘宝。在逛的过程中,消费者往往会选择多个商品后才会下单,所以逛的流量远远要比下单的流量高。当有千百万个消费者一起在逛的时候,会数量级地放大数据库读链路的查询压力。


在数据库层面,往往一个商品 ID 对应数据库内的一行记录。消费者下单那一刻核销资产或者卡券,在关系数据库里被称为完成了一个事务。为了保证在这样的大促尖峰能够支撑逛的高并发,阿里云在数据库的选择上经历了从开源 MySQL 到 AliSQL 的迭代。


体现在业务层面,消费者如今参加秒杀活动,无论是否是双节的大促高峰期,瞬时就可以得到抢购结果的反馈,不需要等待。在数据库层面实现抢购公平,意味着秒杀活动已经是真正意义上的“拼手速”的事情。


事实上为了保证稳定,往年双 11 为了保证大促高峰能够平稳地过去,在一些计算量比较大或者稳定性风险比较高的地方就会实行降级策略,确保能够平稳度过流量高峰。2021 年开始,阿里巴巴更强调用户体验,所以“必须蹚过这些难关”就是对数据库团队的要求。朱成谈到:“这里面就需要涉及到很多基础链路的改造,只有数据库能力的提升才能够做到。”


在 2021 年双 11 双 12 中,有一种无所不在的技术力保证了整体系统的稳定,如 PolarDB 具备的极致弹性、海量存储和高并发 HTAP 访问的产品特性。值得一提的是存算分离方面,阿里巴巴将神龙 ESC、ESSD 和 PolarDB 的文件系统的技术栈能力组合,能够实现减少内核层面一些没有意义的开销,让很多数据库层面的操作不通过操作系统转换就能直通硬件。仅这一环技术能力的提升,在业务层面能缩减交易订单库的集群规模 40% 以上,提升实时分析型业务数据流转效率 30%。开源属性,也将为 PolarDB 带来更多的想象空间。


除了秒杀场景流量峰值的情况,在日常的业务中,还是需要低成本维持业务稳定性,这就要求数据库存储机头能够实现升降配。“大促的时候用比较高规格的存储机头,就是计算存储节点,一些熟悉数据库朋友的可能把它定义为引擎层、执行层,那是一个高规格的数据执行节点,但是我在日常不需要这么好的节点,就意味着它有个升降配的过程。在没有存储计算分离之前做这个操作,其实是一个挺耗时间的操作。其实降机头的操作就意味着有点像带管的摩托车,只不过马力大一点,马力小一点的问题,不同场景,我再换不同规格的摩托车机头。”徐培德谈道。

让到手价在购物车中清晰可见

当稳定成为常态,业务层的诉求开始被逐一满足。朱成表示,以前消费者更强调买买买,现在则更喜欢逛逛逛,有两个明显的诉求,一是价格能够更加清晰,知道这个东西到手价是多少、券后价是多少,二是用户希望一个订单里面可以支持多个地址,可以在一键下单的时候享受更多的优惠和折扣,达到最高的性价比。


券后到手价的实现依赖数据库两方面的能力,算力和数据存取。如果仅仅依靠 RDS 去做升配或者扩容,成本将难以预估。数据库作为底层产品,重要的三个指标就是成本、效率和稳定性。在做产品选择时,需要系统考虑这三个指标。因此,阿里巴巴数据库团队推出了 Tair 内存数据库。“Tair 在此之前,不管是用作缓存还是持久存储,更多是 KV 类数据结构。但是我们需要的是一种关系型的、结构化的存取能力,所以 Tair 推出了 SQL 模型,我们称之为 TairSQL,一个关系型的内存数据库,用一个比较低的硬件成本,来提供一个高性能的读写并发能力。”徐培德介绍道。


当消费者在逛的过程中,一旦下单,卡券就会核销或者冻结,资产状态随即更新到 TairSQL 中,对于异构数据源间低时延提出了更高要求。与此同时,用户资产的数据量非常大,如果全用内存,那整体存储成本非常昂贵。“高性能、大容量、低成本的要求,看似很难平衡,但这在 Tair 上得到了很好的解决。Tair 近几年深耕的持久内存技术很好匹配了当今众多的类似场景,也就是在云上正在售卖的 Tair 持久内存形态(Tair-PMEM)。今天 Tair 采用持久内存之后,做到了每个操作都持久化,性能吞吐几乎与内存持平。同时整个存储的空间通过新型的硬件,容量可以提升一个数量级。”陈锦赋谈到。


也就是说,PMEM 和 Tair 的结合,实现了超大内存存储,能够将消费者平台红包、店铺红包、平台优惠券、店铺优惠券、店铺会员折扣、店铺限时折扣等几十项资产进行持久化归一存储,让业务在计算价格时,可以从一个地方获取所有数据。此外,Tair 内存数据库整体架构采用 share-nothing 架构,并为用户提供了分区单线程 ACID 能力。在水平扩展的集群中,每个节点服务数十个分区,每个分区使用单独线程响应的事务处理模型避免了锁竞争的开销。据悉,在大促场景下,Tair 提供了几乎直线般的 P99 访问延时。

让历史订单能够实时检索

第二个被满足的业务层诉求就是双节期间历史订单能被实时检索。这个功能也是过往在大促高峰时会被降级的功能。淘宝发展至今,累积了大量的历史订单数据,在做好这些数据存储的基础上还要实现精准地检索,并不是一件容易的事情。用户的订单检索依赖的是模糊匹配功能,仅依赖数据库很难实现精准检索的体验。一方面,数据库需要对消费者输入的关键词语义进行高相关性的匹配,比如搜索一个茶杯带回的数据包括茶杯和茶具。


这样的描述很容易让技术人联想到搜索引擎。搜索引擎的确在功能上能够满足这些诉求,在技术上也非常成熟,但是应用在企业内部仅为了实现这一项功能,成本太高。“特别在阿里内部的话,为了给用户一个比较及时体验,他几乎可以认为他的索引是全内存状态去保存的。”徐培德谈道。发展近 20 年,淘宝积累了千亿级别的订单数量,“千亿级别的订单量的索引列,全部丢进内存的话,我的机器成本肯定是兜不住的。”


最终,阿里巴巴团队和数据库团队一起选择了 ADB(AnalyticDB),早在 2015、2016 年就可以通过离线的方式将数据输入,通过 Ad Hoc 即席查询,不仅能保证订单新增不受影响,还具有丰富的检索相关性排序。2019 年 7 月,分析型数据库 ADB 3.0(AnalyticDB for MySQL 3.0) 发布,高度兼容 MySQL 协议以及 SQL:2003 语法标准,支持对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。在 2021 年的双 11 双 12 中,ADB 3.0 真正实现了无论是否在峰值场景,都能让历史订单实时检索。


具体而言,ADB 3.0 解决了三方面的问题:

  1. 全量数据迁移与实时同步。DMS 库仓一体化架构,借助 DTS 高效传输能力,将 MySQL 全量数据迁移至 ADB,并保持实时同步。

  2. 行级存储能力。ADB 存储格式采用行列混存的 PAX 格式,能够提供高效的基于行号的随机查找能力,又可以按照 Chunk 粒度切分读取的并行度,多 Chunk 并行扫描,提高离线读吞吐性能,兼顾在线低延迟查询和离线高吞吐场景。

  3. 自适应索引。在应对订单搜索需求随时变化的情况下,ADB 自研自适应索引框架,支持字符串 InvertIndex、位图索引、KDTree 索引、JSON 索引和向量索引五种索引类型,列级不同类型的索引可以支持多种条件(交、并、差)的任意组合,相比较传统数据库,无需手工构建组合索引,且支持 OR/NOT 等更多条件的索引下推。


如今,ADB 3.0 让阿里巴巴拿到了订单搜索业务上的高满意度,相比 2020 年的单项客诉量降低了 86% 左右。在陈锦赋看来,云原生数据仓库 ADB3.0 很大的一个价值部分在于能够实现数据的在线化实时化,能够挖掘到一些目前还未被发现到的商业价值。“那这背后对于一个新的数据库产品类型的要求,实际上整个业界大家都是在探索阶段。”

写在最后

双 11 双 12 背后的数据库技术支持远不止于此。一个订单达成交易的背后,数据库层面有近 50 次请求的实现,远不是一款单一的数据库产品提供的支持。双 11 双 12 丰富的运营活动和千亿交易额背后,数据库层面是包括 RDS、PolarDB、Tair、ADB(ADB3.0) 以及 Lindorm 等数据库产品提供的组合技。


2021 年是阿里巴巴首个云上 100% 上云的双 11 的一年,也是阿里云数据库全面云原生化的一年,但是峰值计算成本相比 2020 年下降了 50%,云数据库巨大的商业价值和潜力可见一斑。云原生数据库未来的优势和带来的价值,也将超过数据库本身。

2022-01-25 10:366238

评论

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

三周 作业

水浴清风

LeetCode题解:77. 组合,回溯+for循环,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

第三周 总结

willson

极客大学架构师训练营

抽象工厂模式

猴子胖胖

设计模式 Go 语言

Chrome浏览器引擎 Blink & V8

曲迪

Java chrome 大前端 blink V8

架构师训练营第 1 期 -- 第七周学习总结

发酵的死神

极客大学架构师训练营

架构师训练营第七周学习总结

吴传禹

极客大学架构师训练营

架构师训练营第 1 期 -- 第七周作业

发酵的死神

极客大学架构师训练营

计算机的时钟(四):TrueTime

ElvinYang

第三周课后练习

刘洋

极客大学架构师训练营

架构师训练营第三周心得

小兵

设计模式 - 学习总结笔记

Xuenqlve

架构师训练营第 1 期 - 第 7周 - 学习总结

wgl

第 3 周 代码重构作业

心在那片海

第三周 命题作业

willson

架构师训练营第2期-第3周作业1

xiaomao

架构训练营第三周作业

小兵

性能优化(1)

wing

极客大学架构师训练营

架构师训练营第二期 Week 3 总结

bigxiang

极客大学架构师训练营

第 3 周 代码重构总结

心在那片海

架构师训练营第七周作业

吴传禹

极客大学架构师训练营

第三周作业

hunk

极客大学架构师训练营

Week_07 总结

golangboy

极客大学架构师训练营

性能测试 课后作业

ABS

单例模式

猴子胖胖

设计模式 Go 语言

第3周作业

Steven

极客大学架构师训练营

二期第三周作业

supersky6

第三周-作业1

Mr_No爱学习

成为架构师 - 架构师训练营第 03 周

陈永龙Vincent

性能压测的时候,随着并发压力的增加,系统响应时间和吞吐量如何变化

Jacky.Chen

周练习 7

何毅曦

首次揭秘双11双12背后的云数据库技术!_服务革新_张俊宝_InfoQ精选文章