2017双11技术揭秘—阿里数据库计算存储分离与离在线混布

作者:吕建枢(吕健)

背景

随着阿里集团电商、物流、大文娱等业务的蓬勃发展,数据库实例以及数据存储规模不断增长,在传统基于单机的运维以及管理模式下,遇到非常多的困难与挑战,主要归结为:

  1. 机型采购与预算问题
    在单机模式下计算资源(CPU和内存)与存储资源(主要为磁盘或者SSD)存在着不可调和的冲突;计算与存储资源绑定紧密,无法进行单独预算。数据库存储时,要么计算资源达到瓶颈,要么是存储单机存储容量不足。这种绑定模式下,注定了有一种资源必须是浪费的。
  2. 调度效率问题
    在计算与存储绑定的情况下,计算资源无法做无状态调度,导致无法实现大规模低成本调度,也就无法与在大促与离线资源进行混布。
  3. 大促成本问题
    在计算资源无法做到调度后,离线混布就不再可能;为了大促需要采购更多的机器,大促成本上涨严重。

因此,为了解决诸多如成本,调度效率等问题,2017年首次对数据库实现计算存储分离;计算存储分离后,再将计算节点与离线资源混布,达到节省大促成本的目的。

2017年数据库计算存储分离,

使得数据库进行大规模无状态化容器调度成为可能!

使得数据库与离线业务混布成为可能!

使得低成本支持大促弹性成为可能!

在高吞吐下,总存储集群整体RT表现平稳,与离线资源联合首次发力,完成2017年“11.11”大促的交易支撑。

计算存储分离

在所有业务中,数据库的计算存储分离最难,这是大家公认的。因为数据库对于存储的稳定性以及单路端到端的时延有着极致的要求:

存储稳定性

在分布式存储的稳定性方面,我们做了非常多的有意探索,并且逐一落地。这些新技术的落地,使得数据库计算存储分离成为可能:

单机failover

单机failover我们做到业界的极致,5s内完成fo,对整体集群的影响在4%以内(以集群规模24台为例,集群机器越多,影响越小)。另外,我们对分布式存储的状态机进行加速优化,使得基于paxos的选举在秒级内进行集群视图更新推送。

长尾时延优化

计算存储分离后,所有的IO都变成了网络IO,因此对于单路IO时延影响的因素非常多,如网络抖动,慢盘,负载等,而这些因素也是不可避免的。我们设计了“副本达成多数写入即返回的策略(commit majority feature)”,能够有效地使长尾时延抖动做到合理的控制,以满足业务的需求。

以下是commit majority feature开起前后的效果对比。其中“蓝色”为优化后的长尾时延,“红色”为优化前长尾时延,效果非常显著。

流控

我们实现了基于滑动窗口的流控功能,使得集群后台活动(如backfill和recovery)能根据当前的业务流量进行自适配的调整,在业务与后台数据恢复之间做到最佳平衡。

一般如果集群后端活动太低,会影响数据恢复,这会提高多盘故障的概率,降低了数据的可靠性。我们经过优化后,通过滑动窗口机制,做到了前后端数据写入的速动,在不影响业务写入的情况下,尽最大可能提高数据恢复速度,保证多副本数据的完整性。

提高数据重平衡的速度,也是为了保证整个集群的性能。因为一出现数据倾斜时,部分盘的负载将变大,从而会影响整个集群的时延和吞吐。
流控效果如下:

高可用部署

在高可用部署上,我们引入的故障域的概念。多个数据副本存储在多个故障域,分布到至少4个RACK以上的机架上,用于保障底层机柜电源以及网络交换设备引起的故障等。

为了能够更好的理解数据副本存储位置(data locality),需要知道数据散射度(scatter width)的概念。怎么来理解数据散射度?

举个例子:我们定义三个copy set(存放的都是不同的数据):{1,2,3},{4,5,6},{7,8,9}。任意一组copy set中存放的数据没有重复,也就是说一份数据的三个副本分别放置在:{1,4,7}或者{2,5,8}或者{3,6,9}。那么这个时候,其数据散射度远小于随机组合的C(9,3)。

随机组合时,任意3台机器Down机都会存在数据丢失。而采用此方案后,只有当{1,4,7}或者{2,5,8}或者{3,6,9}其中的任意一个组合不可用时,才会影响高可用性,才会有数据丢失。

综上可知,我们引入copy set的目标就是尽量的降低数据散射度“S”。下图中两组replica set,其中每一组的三个副本分别放置到不同的RACK中。

我们的优化还有很多,这里不再一一列举。

数据库吞吐优化

当所有的IO都变成网络IO后,我们要做的就是如何减少单路IO的延迟,当然这个是分布式存储以及网络要解的问题。

分布式存储需要优化自身的软件stack以及底层SPDK的结合等。

而网络层则需要更高带宽以及低时延技术,如25G TCP或者25G RDMA,或者100G等更高带宽的网络等。

但是我们可以从另外一个角度来考虑问题,如何在时延一定的情况下,提高并发量,从而来提高吞吐。或者说在关键路径上减少IO调用的次数,从而从某种程度上提高系统的吞吐。

大家知道,影响数据库事务数的最关键因素就是事务commit的速度,commit的速度依赖于写REDO时的IO吞吐。所谓的REDO也就是大家熟知的WAL(Write Ahead Log)日志。

在脏数据flush回存储时,日志必须先落地,这是因为数据库的Crash Recovery是重度以来于此的。在recovery阶段,数据库先利用redo进行roll forward,再利用undo进行roll backward,最后再撤销用户未提交的事务。

因此,存储计算分离下,要想在单路IO时延一定时提高吞吐,就必须要优化commit提交时的效率。我们通过优化redo的写入方式,让整个提高吞吐100%左右。另外,也可以优化redo group commit的大小,结合底层存储stripe能力,做并发与吞吐优化。

数据库原子写

在数据库内存模型中,数据页通常是以16K做为一个bufferpage来管理的。当内核修改完数据之后,会有专门的“checkpoint”线程按一定的频率将Dirty Page flush到磁盘上。我们知道,通常os的page cache是4K,而一般的文件系统block size也是4K。所以一个16k和page会被分成4个4k的os filesystem block size来存储,物理上不能保证连续性。

那么会带来一个严重的问题,就是当fsync语义发出时,一个16k的pageflush,只完成其中的8k,而这个时候client端crash,不再会有重试;那么整个fsync就只写了一半,fsync语义被破坏,数据不完整。上面的这个场景,我们称之为“partial write”。

对于MySQL而言,在本地存储时,使用Double Write Buffer问题不大。但是如果底层变成网络IO,IO时延变高时,会使MySQL的整体吞吐下降,而Double Write Buffer会加重这个影响。

我们实现了原子写,关闭掉Double Write Buffer,从而在高并发压力及高网络IO时延下,让吞吐至少提高50%以上。

网络架构升级

分布式存储,对于网络的带宽要求极高,我们引入了25G网络。高带宽能更好的支持阿里集团的大促业务。另外,对于存储集群后台的活动,如数据重平衡以及恢复都提供了有力的保障。

离在线混布

计算存储分离后,离在线混布成为可能;今年完成数据库离在线混布,为2017年大促节省了计算资源成本。

在与离线混布的方案中,我们对数据库与离线任务混跑的场景进行了大量的测试。

实践证明,数据库对时延极度敏感,所以为了达到数据库混布的目的,我们采用了以下的隔离方案:

CPU与内存隔离技术

CPU的L3是被各个核共享的,如果在一个socket内部进行调度,会对数据库业务有抖动。因此,在大促场景下,我们会对CPU进行独立socket 绑定,避免L3 cache干扰;另外,内存不超卖。当然,大促结束后,在业务平峰时,可以择机进行调度和超卖。

网络QOS

我们对数据库在线业务进行网络打标,NetQoS中将数据库计算节点的所有通信组件加入到高优先级group中。

基于分布式存储的弹性效率

基于分布式存储,底层分布式存储支持多点mount,用于将计算节点快速弹性到离线机器。

另外,数据库Buffer Pool可以进行动态扩容。大促ODPS任务撤离,DB实例Buffer Pool扩容;大促结束后,Buffer Pool回缩到平峰业务时的大小。

双11大促求证

大促期间,其中一个库吞吐达到将近3w tps,RT在1ms以内,基本上与本地相当,很好的支撑了2017年大促。这就是我们今年所做的诸多技术创新的结果。

展望

目前我们正在进行软硬件结合(RDMA,SPDK)以及上层数据库引擎与分布式存储融合优化,性能将会超出传统SATA SSD本地盘的性能。

RDMA和SPDK的特点就是kernel pass-by。未来,我们数据库将引入全用户态IO Stack,从计算节点到存储节点使用用户态技术,更能充分满足集团电商业务对高吞吐低时延的极致要求。

这些网络和硬件技术的发展,将会给“云计算”带来更多的可能性,也会给真正的“云计算”新的商业模式带来更多憧憬,而我们已经在这条阳光的大道上。

欢迎有更多的存储及数据库内核专家一起参与进来,一起携手迈进未来。

【引用】

[1] Copysets:Reducing the Frequency of Data Loss in Cloud Storage

[2] CRUSH: Controlled,Scalable, Decentralized Placement of Replicated Data

时间: 2024-12-25 23:25:34

2017双11技术揭秘—阿里数据库计算存储分离与离在线混布的相关文章

2017双11技术揭秘—阿里巴巴数据库技术架构演进

作者:谌文涛(俞月) 每年电商双11大促对阿里技术人都是一次大考,对阿里数据库团队更是如此.经过9年的发展,双11单日交易额从2009年的0.5亿一路攀升到2017年的1682亿,秒级交易创建峰值达到了32.5万笔/秒.支撑这一切业务指标的背后,是底层技术体系的一次次迭代升级. 阿里巴巴数据库系统经历了10多年的发展,今年正式确定从 第三代大规模分库分表 向 第四代X-DB分布式数据库系统 演进的目标.X-DB分布式数据库的落地已经在2017年双11大促中获得了可行性验证,同时底层开始引入存储计

2017双11技术揭秘—X-DB支撑双11进入分布式数据库时代

作者:章颖强(江疑).胡炜 X-DB 1.0(X-Cluster)是阿里自主研发的,100%兼容MySQL生态的,全球级分布式强一致的关系型数据库系统.今年双11是X-DB的第一次大考,本次双11X-DB服务于天猫/淘宝核心交易系统.核心物流系统.核心IM系统,经受了零点业务32.5万笔/秒峰值的性能考验(对应数据库峰值每秒破亿次的SQL调用):同时X-DB支撑起了新一代单元化架构,在分布式一致性算法Paxos的统一框架下,第一次提供了跨Region分布式强一致能力,实现高效的跨Region数据

2017双11技术揭秘—千亿级流量来袭,如何用硬件加速技术为CPU减负?

作者:王发康(毅松) 主站接入层是阿里2015年全站HTTPS项目诞生的产品,目前已经承载集团90%以上的入口流量.2016年主站接入层不仅在运维自动化.高可用领域取得重大突破,而且软件层面上也做过很多性能优化,促使2016年双11平稳度过.秉着软硬件结合的性能优化思想,2017年主站接入层在硬件加速领域迈出了第一步.在刚过去的2017年双11零点流量高峰的考验下,主站接入层Tengine Gzip硬件加速机器运行平稳.同等条件下相比于未开启QAT加速的机器性能提升21%左右. 背景介绍 众所周

2017双11技术揭秘—TDDL/DRDS 的类 KV 查询优化实践

作者:励强(君瑜) 场景介绍 性能优化是企业级应用永恒的话题,关系型数据库查询优化更是如此.在前台核心业务场景中,类 KeyValue 查询(以下简称类 KV 查询)是非常常见的(例如,SELECT id, name FROM users WHERE id=1002),并且在应用总 SQL 流量占比很高,例如,天猫某核心业务的类 KV 查询占比近90%,商品某系统中占比近80%,交易订单系统中占比也有50%左右,菜鸟等其他核心业务场景中这个现象也是相当普遍. 这类 SQL 已经非常简单,如果仅在

2017双11技术揭秘—双十一海量数据下EagleEye的使命和挑战

作者:王华锋(水彧) 背景 双十一一直是阿里巴巴集团每年要打的一场大战役.要打赢这场战役,技术上,不仅仅是几个应用.几个系统的事,也不是多少个开发+多少个测试就能完成的事,而是需要各大系统协同作战.每个应用各司其职.技术人员通力合作才能取得最终的胜利. EagleEye作为阿里集团老牌的链路跟踪系统,其自身业务虽不在交易链路上,但却监控着全集团的链路状态,特别是在中间件的远程调用上,覆盖了集团绝大部分的场景,在问题排查和定位上发挥着巨大的作用,保障了各个系统的稳定性,为整个技术团队打赢这场战役保

2017双11技术揭秘—分布式缓存服务Tair的热点数据散列机制

作者:刘欢(浅奕) 1 问题背景 分布式缓存一般被定义为一个数据集合,它将数据分布(或分区)于任意数目的集群节点上.集群中的一个具体节点负责缓存中的一部分数据,整体对外提供统一的访问接口[1].分布式缓存一般基于冗余备份机制实现数据高可用,又被称为内存数据网格(IMDG, in-memory data grid).在云平台飞速发展的今天,作为提升应用性能的重要手段,分布式缓存技术在工业界得到了越来越广泛的关注和研发投入[2].弹性缓存平台[3]是分布式缓存集群在云计算场景下的新形态,其强调集群的

97期:大流量与高并发—双11技术盘点

本期头条   [峰会回顾]8月30-31日我们成功举办了"蚂蚁金服&阿里云在线金融技术峰会",本次峰会聚焦数据库.应用架构.移动开发.机器学习等热门领域,帮助金融业技术开发者深入解析互联网应用的前沿应用与技术实践.目前活动视频.整理文章已经出炉,点击收藏. • 大流量与高并发:双11技术盘点 • 阿里云开源DataX 3.0:异构数据源离线同步工具,支持10余款主流开源数据库 最新资讯   阿里云中标国税总局大数据专有云项目,中标金额近四千万元点击查看 据中国政府采购网公示消息

揭秘2017双11背后的网络-双11的网络产品和技术概览

引言 揭秘2017双11背后的网络-一张图读懂2017双11中的网络产品和技术 揭秘2017双11背后的网络-双11的网络产品和技术概览 揭秘2017双11背后的网络-直面双11洪峰的负载均衡SLB 揭秘2017双11背后的网络-全球最大混合云架构 注:如果对网络产品还不太了解的,推荐阅读 一张图看懂阿里云网络产品[一]网络产品概览 下面分别对双11中的主要网络产品-专有网络VPC,负载均衡SLB,NAT网关,高速通道以及混合云架构进行介绍 VPC-安全的网络容器 专有网络VPC(Virtual

零点之战!探访阿里巴巴8大技术专家,提前揭秘2017双11关键技术

点击进入阿里云双11主会场 摘要:在距离双11已经不到10天的这个时刻,一场看不见硝烟的战争似乎已经打响.随着一年一度购物狂欢的即将到来,网上出现了很多阿里技术应对双11的段子."阿里工程师拜关公求服务器不宕机","技术人员围着被子敲代码"等传闻也被消费者们所津津乐道.那么,针对双11期间极为严苛的技术压力,阿里巴巴究竟是用怎样的方式进行解决的呢?在接下来的文段中,就让我们一起来对阿里巴巴在2017双11背后的技术进行一次细致的了解和探访.   阿里巴巴针对双11的