【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

首次揭秘双 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:365714

评论

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

Redis 学习笔记 08:数据结构与对象小结

架构精进之路

redis 七日更 28天写作

胜天半子!阿里内部力荐SpringBoot全栈笔记全网首发,源码实战齐飞

Java架构之路

Java 程序员 架构 面试 编程语言

你kin你擦!阿里终于肯把内部高并发编程高阶笔记开源出来了

Java架构之路

Java 程序员 架构 面试 编程语言

跨界融合,区块链推动实体经济提档升级

CECBC

人工智能 云计算 大数据

永续合约APP系统软件开发

系统开发

程序员生产环境-软件篇

ITCamel

程序员 效率工具 工作效率

第一周作业

Esther

AES128解密只能解一半的问题

李日盛

AES 问题定位

技术分享 | 漫谈音视频中的拥塞控制

拍乐云Pano

企业短信服务质量与用户体验如何监控?短信监测技术震撼来袭

博睿数据

短信 数据监测

架构师训练营第三周作业 - 学习总结

阿德儿

百度首届智能小程序高校大赛圆满结束:关注学生心理健康小程序获全国一等奖

DT极客

​Kubernetes资源清单篇:如何创建资源?​

xcbeyond

Kubernetes 28天写作 Kubernetes从入门到精通

客户服务高触达,零代码从短信/邮件跳转小程序客服

环信

数字货币应用从C端走向B端 实践中这些难题仍需关注

CECBC

数字货币

Soul网关源码阅读(八)路由匹配初探

Java 源码阅读 网关

蝉联 Apache 最活跃项目,Flink 社区是如何保持高速发展的?

Apache Flink

flink

阿里开源SpringSecurity:用户+案例+认证+框架

996小迁

Java 程序员 架构 面试 springsecurity

观看辽篮比赛,思考团队管理——关于团队的灵魂拷问,你中了几个?

伯薇

团队管理 团队建设 团队 赋能 激励

【盘点2020】机房网络性能哪家强?年度冠军揭晓

博睿数据

机房 评测

EXCEL数据太“脏”无从下手?何须用python,ETL一分钟搞定

智分析

Excel ETL

万字带你深入阿里开源的Canal工作原理

大数据老哥

大数据 canal

为什么你家的 K8s 应用平台不好用?

孙健波

Kubernetes PaaS KubeVela

实现数字经济和实体经济深度融合

CECBC

区块链

边缘安全 | 正确使用CDN 让你更好规避安全风险

阿里云Edge Plus

安全 CDN

LeetCode题解:105. 从前序与中序遍历序列构造二叉树,递归+哈希表,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

阿里云 RTC QoS 屏幕共享弱网优化之若干编码器相关优化

阿里云视频云

音视频 WebRTC 网络 RTC 视频会议

一文读懂 Serverless,将配置化思想复用到平台系统中

Serverless Devs

Serverless 云原生 PaaS

Android面试(二)

我就感觉到快

关于JDK15的简单理解

Java架构师迁哥

大数据知识专栏 -MapReduce 自定义排序技术

小马哥

大数据 hadoop mapreduce 七日更

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