>

新一代数据库技术在双11中的黑科技,阿里数据库

- 编辑:金沙国际平台登录 -

新一代数据库技术在双11中的黑科技,阿里数据库

第十个双11即将来临之际,阿里技术推出《十年牧码记》系列,邀请参与历年双11备战的核心技术大牛,一起回顾阿里技术的变迁。

12月13-14日,由云栖社区与阿里巴巴技术协会共同主办的《2017阿里巴巴双11技术十二讲》顺利结束,集中为大家分享了2017双11背后的黑科技。本文是《新一代数据库技术在双11中的应用》演讲整理,本文主要从数据库上云和弹性调度开始谈起,重点分享了新一代数据库以及其在双11中的应用,包括X-DB、X-KV和ESDB等。内容如下。

今天,阿里数据库事业部研究员张瑞,将为你讲述双11数据库技术不为人知的故事。在零点交易数字一次次提升的背后,既是数据库技术的一次次突破,也见证了阿里技术人永不言败的精神,每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。

分享嘉宾:

图片 1阿里数据库事业部研究员张瑞

张瑞:阿里巴巴研究员,阿里集团数据库技术团队负责人,经历阿里数据库技术变革历程,连续六年作为数据库总负责人参与双11备战工作。

再过几天,我们即将迎来第十个双11。过去十年,阿里巴巴技术体系的角色发生了转变,从双11推动技术的发展,变成了技术创造新商业。很多技术通过云计算开始对外输出,变成了普惠的技术,服务于各个行业,真正做到了推动社会生产力的发展。

双11是一场技术大练兵,是互联网界的超级工程。需要做到支撑尽可能高的零点峰值,给用户最好的体验;也要做到成本尽可能低,要求极致的弹性能力;还要做到整体系统的稳定。

这十年,阿里巴巴数据库团队一直有一个使命:推动中国数据库技术变革。从商业数据库到开源数据库再到自研数据库,我们一直在为这个使命而努力奋斗。

数据库如何实现极致弹性能力

数据库上云

数据库实现弹性是比较难的,数据库对性能要求非常高,因此,必须实现数据库上云,但是如何上云呢?

数据库上云面临以下几个难点:

1.数据库如何上云,并快速构建混合云?

2.如何降低虚拟化带来的性能损耗?

3.公有云环境和内部网络的互通问题。

经过几年的探索,这些难点都已得到解决。第一,高性能ECS可以和物理机性能一样,主要使用了SPDK、DPDK技术和NVMe存储,让虚拟化损耗非常小,接近物理机;第二,数据库弹性混合云问题得到解决,可以同时管理云上和云下环境,用户可以在双11前把混合云构建起来,支撑双十一峰值。

数据库弹性调度

只有上云是远远不够的,还要进行离在线混布。而数据库实现弹性调度的两大基础条件是容器化和计算存储分离。容器性能需要与物理机持平,存储计算分离依赖于硬件的发展,25G网络和高性能分布式存储盘古让其成为可能。

数据库存储计算分离架构如图,包括存储层、网络层和计算层,存储使用阿里自研分布式存储系统-盘古,数据库计算节点则部署在阿里自研容器(Pouch)中,除此以外,还有存储管控系统。

为了实现存储和计算分离,我们在存储上做了许多工作,包括:

二三异步:第三个副本异步完成,平均延时降低10%以上,4个9 latency降低3-4倍;

QoS流控:根据前台业务负载情况控制后台IO流量,保证写入性能;

快速Failover:存储集群单机FO优化为5s,达到业界领先水平;

高可用部署:单集群四Rack部署,将数据可靠性提升到10个9。

在数据库方面我们也做了大量优化,最重要的是降低网络吞吐,以此来降低网络延迟对于数据库性能的影响。比如:redo sync优化,吞吐提升100%;由于盘古存储支持原子写,所以我们关闭Double Write Buffer,高压力下吞吐提升20%,带宽节省100%。

双11数据库混布技术

容器化和存储计算分离,使得数据库无状态化,具备调度能力。在双11高峰,通过将共享存储挂载到不同的计算集群(离线集群),实现数据库的快速弹性。

图片 2

阿里新一代数据库技术

阿里最早是商业数据库,然后我们做去IOE,研发出阿里MySQL分支AliSQL和分布式中间件TDDL。2016年,我们开始思考新一代数据库技术X-DB,X代表追求极限性能,挑战无限可能的含义。

阿里的业务场景对于数据库有很高的要求:

数据要可扩展;

持续可用、数据要强一致;

数据量大、重要程度高;

数据有明显的生命周期特性,冷热数据特点鲜明;

交易、库存,支付等业务,操作逻辑简单,要求高性能。

因此,定义新一代数据库就要包含几个重要特点:具备数据强一致、全球部署能力;内置分布式、高性能、高可用能力;具备自动数据生命周期管理能力。

X-DB架构图

X-DB架构如图,引入Paxos分布式一致性协议解决问题;可异地部署,虽然网络延时增加,但能够保持高性能(吞吐),在同城三节点部署模式下,性能与单机持平,同时具备网络抖动的高容忍性。

X-DB核心技术之一:高性能Paxos基础库X-Paxos是实现三节点能力的核心,可实现跨AZ、Region的数据强一致能力,实现5个9以上的持续可用率。

X-DB核心技术之二:Batching & Pipelining。X-DB在事务提交时,必须保证日志在数据库节点的多数派收到并提交,这是保证数据强一致基础,由于事务在提交时必须需要跨网络,这一定会导致延时增加,要保证高延时下的吞吐是非常困难的。Batching & Pipelining技术保证尽可能批量提交,数据可以乱序接收和确认,最终保证日志顺序提交。可以在高延时的情况下,保持很高的吞吐能力。

X-DB核心技术之三:异步化提交,数据库线程池在提交时会等待,为了最大程度提升性能,我们采用了异步化提交技术,最大可能保证数据库线程池可以高效工作。通过这些技术保证X-DB在三节点模式下的高吞吐量。

X-DB与MySQL Group Replication的对比测试

我们与Oracle官方的Group Replication作对比。在三节点同IDC部署模式下,sysbench标准化测试。Insert场景,我们可以做到MySQL官方的2.4倍,响应时间比官方低。

在三节点三地部署模式下,sysbench标准化测试。Insert场景,X-DB(5.04万)性能优势特别明显,是MySQL GR(0.85万)的5.94倍,响应延时X-DB(58ms)是MySQL GR(150ms)的38%。

典型应用场景

同城跨AZ部署替代传统主备模式,我们把原来主备模式变成三节点,解决跨AZ数据质量问题和高可用问题。跨AZ数据强一致,单AZ不可用数据零丢失、单AZ不可用秒级切换、切换自封闭,无第三方组件。相对主备模式零成本增加。

跨Region部署,用更底层的数据库技术解决异地多活问题,三地六副本(主备模式)降低为三地四副本(三地五节点四数据),对于业务来说,可以享受跨Region数据强一致,单个Region不可用零数据丢失;跨Region强同步下依然保持高性能;切换策略灵活,可以优先切换同Region,也可定制跨Region切换顺序。

如果将阿里数据库发展历史分为三个阶段的话,分别是:

数据库在双11中的黑科技

X-KV在双11中的应用

X-KV是基于MySQL Memcached plugin的增强,今年我们做了大幅度的改进,支持更多数据类型,支持非唯一索引、组合索引,支持Multi get 功能,支持Online Schema change,最大变化是通过TDDL支持SQL转换。对于业务方,X-KV优势是超高读取性能,数据强一致;减少应用响应时间,降低成本;同时支持SQL,应用可以透明迁移。

TDDL for X-KV优化如下:

独立KV连接池:SQL和KV连接池相互独立;变更时,两套连接池保持协同一致;应用可以快速在两套接口之间切换。

优化的KV通信协议:不再需要分隔符,协议实现。

结果集自动类型转换:字符串自动转换为MySQL类型。

交易卖家库的性能瓶颈解决方案

随着双11交易量增长,近两年交易卖家库的同步延时一直比较大,导致商户不能及时处理双11订单;且卖家库有大量复杂的查询,性能差。我们曾经通过为大卖家设置独立队列、同步链路合并操作和卖家库限流等进行优化,但仍然没有完全解决问题。

ESDB是基于ES打造的分布式文档数据库,我们在ES的基础上,支持了SQL接口,应用可以从MySQL无缝迁移到ESDB;针对大卖家,提供动态二级散列功能,解决大卖家同步的性能瓶颈。同时还做了大量的性能优化和限流保护等功能。

数据库监控系统演进

数据库秒级监控的技术挑战有很多,具体有以下四点:

1.海量数据:平均每秒处理1000万项监控指标,峰值1400万;

2.复杂的聚合逻辑:地域、机房、单元、业务集群、数据库主备等多维度数据聚合;

3.实时性要求高:监控盯屏需要立即看到上一秒的监控数值;

4.计算资源:占用尽可能少的资源进行采集和计算。

整个链路经历三代架构:第一代,Agent + MySQL;第二代,Agent + datahub + 分布式NoSQL;第三代,Agent + 实时计算引擎 + HiTSDB。

HiTSDB是阿里自研的时序数据库,通过实时计算引擎将秒级性能数据、全量SQL运行状况进行预先处理后,存储在HiTSDB中。通过第三代架构,实现了双11高峰不降低的秒级监控能力,这对我们了解系统运行状况、诊断问题是非常有帮助的。

CloudDBA在双11中的应用

阿里拥有业界最富有经验的DBA,海量的性能诊断数据。我们的目标是把阿里DBA的经验、大数据和机器智能技术结合起来,目标是三年后不再需要DBA做数据库诊断、优化等工作,而是让机器来完成数据库的智能化管理。我们认为自诊断、自优化、自运维是未来数据库技术发展的重要方向。

CloudDBA在今年双11也做了一些探索,通过对全量SQL以及监控数据的分析,我们实现了SQL自动优化(慢SQL调优)、空间优化(无用表无用索引分析)、访问模型优化(SQL和KV)和存储空间增长预测等功能。

展望明年双11,Higher,Faster,Smarter

更高:更高交易创建峰值;

更快:高性能数据库、高性能存储;

更智能:CloudDBA发挥更大价值。

  • 第一阶段(2005-2009)商业数据库时代;
  • 第二阶段(2010-2015)开源数据库时代;
  • 第三阶段自研数据库时代。

商业数据库时代就是大家所熟知的IOE时代,后来发生了一件大事就是“去IOE”:通过分布式数据库中间件TDDL、开源数据库AliSQL(阿里巴巴的MySQL分支)、高性能X86服务器和SSD,并通过DBA和业务开发同学的共同努力,成功地替换了商业数据库Oracle、IBM小型机和EMC高端存储,从此进入了开源数据库时代。

去IOE带来了三个重大的意义:

第一是解决了扩展性的问题,让数据库具备了横向扩展的能力,为未来很多年双11零点交易峰值打下了很好的基础。

第二是自主可控,我们在AliSQL中加入了大量的特性,比如:库存热点补丁,SQL限流保护,线程池等等,很多特性都是来源于双11对于数据库的技术要求,这在商业数据库时代是完全不可能的。

第三是稳定性,原来在商业数据库时代,就如同把所有的鸡蛋放在一个篮子里,去IOE之后不仅仅解决了单机故障,更是通过异地多活的架构升级让数据库跨出了城市的限制,可以实现数据库城市间的多活和容灾,大大提升了系统的可用性。

图片 3

进入2016年,我们开始自研数据库,代号X-DB。大家一定会问:为什么要自研数据库?有以下几个原因:

第一,我们需要一个能够全球部署的原生分布式数据库,类似于Google Spanner。

第二是双11的场景对数据库提出了极高的要求:

  • 性能:在双11零点需要数据库提供非常高的读写能力;
  • 存储成本:数据库使用SSD来存储数据,而数据存在明显的冷热特性,大量冷的历史数据和热的在线数据存放在一起,日积月累,占用了大量宝贵的存储空间,存储成本的压力越来越大。我们经过认真评估后发现,如果继续在开源数据库基础上进行改进已经无法满足业务需求。

第三是新的硬件技术的出现,如果说SSD的大规模使用和X86服务器性能的极大提升推动了去IOE的进程,那么NVM非易失内存,FPGA异构计算,RDMA高速网络等技术将第二次推动数据库技术的变革。

图片 4

伴随着每一年的双11备战工作,机器资源的准备都是非常重要的一个环节。如何降低双11的机器资源成本一直是阿里技术人不断挑战自我的一个难题。第一个解决方案就是使用云资源,数据库从2016年初开始就尝试使用高性能ECS来解决双11的机器资源问题。通过这几年的双11的不断磨练,2018年双11,我们可以直接使用了公有云ECS,并通过VPC网络与阿里巴巴集团内部环境组成混合云,实现了双11的弹性大促。

第二个方案就是在线离线混部,日常让离线任务跑在在线的服务器上,双11大促在线应用使用离线的计算资源,要实现这种弹性能力,数据库最核心要解决一个技术问题就是:存储计算分离。存储计算分离后,数据库可以在双11使用离线的计算资源,从而实现极致的弹性能力。通过使用云资源和混部技术,可以最大程度降低双11交易峰值带来的成本。

图片 5

双11备战中另外一个重要的技术趋势就是:智能化。数据库和智能化相结合也是我们一直在探索的一个方向,比如Self-driving Database等。2017年,我们第一次使用智能化的技术对SQL进行自动优化,2018年,我们计划全网推广SQL自动优化和空间自动优化,希望可以使用这些技术降低DBA的工作负担,提升开发人员效率,并有效提升稳定性。相信未来,在双11的备战工作中,会有越来越多的工作可以交给机器来完成。

图片 6

我从2012年开始参加双11的备战工作,多次作为数据库的队长和技术保障部总队长,在这么多年的备战工作中,我也经历了很多有意思的故事,在这里分享一些给大家。

2012年是我的第一次双11,在此之前,我在B2B的数据库团队,2012年初,整个集团的基础设施团队都合并到了技术保障部,由振飞带领。我之前从来没有参加过双11,第一年参加双11后羿(数据库团队的负责人)就把队长的职责给了我,压力可想而知。那时候备战双11的工作非常长,大概从5、6月份就开始准备了,最重要的工作就是识别风险,并准确评估出每个数据库的压力。

我们需要把入口的流量转换为每个业务系统的压力QPS,然后我们根据业务系统的QPS转换为数据库的QPS,2012年还没有全链路压测的技术,只能靠每个业务系统的线下测试,以及每个专业线队长一次又一次的开会review来发现潜在的风险。

可想而知,这里面存在巨大的不确定性,每个人都不想自己负责的业务成为短板,而机器资源往往是有限的,这时,就完全靠队长的经验了,所以,每个队长所承担的压力都非常巨大。我记得当年双11的大队长是李津,据说他当时的压力大到无法入睡,只能在晚上开车去龙井山顶,打开车窗才能小憩一会。

而我,由于是第一年参加双11,经验为零,完全处于焦虑到死的状态,幸好当年有一群很靠谱兄弟和我在一起,他们刚刚经历了去IOE的洗礼,并且长期与业务开发浸淫在一起,对业务架构和数据库性能如数家珍,了若指掌。通过他们的帮助,我基本摸清了交易整套系统的架构,这对我未来的工作帮助非常大。

经过几个月紧张的准备,双11那天终于到来了,我们做好了最充分的准备,但是一切都是那么地不确定,我们怀着忐忑不安的心情,当零点到来的时候,最坏的情况还是发生了:库存数据库的压力完全超过了容量,同时IC数据库的网卡也被打满了。我记得很清楚,当时我们看着数据库的上的监控指标,束手无策。这里有一个小细节:由于我们根本没有估算到这么大的压力,当时监控屏幕上数据库的压力指标显示超过了100%。

正在这时,技术总指挥李津大喊一声:“大家都别慌!”这时我们才抬头看到交易的数字不断冲上新高,心里才稍微平静下来。事实上,对于IC数据库网卡被打满,库存数据库超过容量,都超出了我们的预期,所以最终我们什么预案也没做,就这样度过了零点的高峰。

因为这些原因,2012年的的双11产生了大量的超卖,给公司带来了很大的损失。那一年的双11后,库存、商品、退款和相应数据库的同学,为了处理超卖导致的问题,没日没夜加了两周的班。而且,我周围很多朋友,都在抱怨高峰时的用户体验实在太糟糕了。我们下决心要在第二年的双11解决这些问题。

2012年的双11结束后,我们就开始着手解决库存数据库的性能提升。库存扣减场景是一个典型的热点问题,即多个用户去争抢扣减同一个商品的库存(对数据库来说,一个商品的库存就是数据库内的一行记录),数据库内对同一行的更新由行锁来控制并发。我们发现当单线程去更新一行记录时,性能非常高,但是当非常多的线程去并发更新一行记录时,整个数据库的性能会跌到惨不忍睹,趋近于零。

当时数据库内核团队做了两个不同的技术实现:一个是排队方案,另一个并发控制方案。两者各有优劣,解决的思路都是要把无序的争抢变为有序的排队,从而提升热点库存扣减的性能问题。两个技术方案通过不断的完善和PK,最终都做到了成熟稳定,满足业务的性能要求,最终为了万无一失,我们把两个方案都集成到了AliSQL(阿里巴巴的MySQL分支)中,并且可以通过开关控制。最终,我们通过一整年的努力,在2013年的双11解决了库存热点的问题,这是第一次库存的性能提升。在这之后的2016年双11,我们又做了一次重大的优化,把库存扣减性能在2013年的基础上又提升了十倍,称为第二次库存性能优化。

2013年堪称双11历史上里程碑式的一年,因为这一年出现了一个突破性的技术-全链路压测。我非常佩服第一次提出全链路压测理念的人-李津,他当时问我们:有没有可能在线上环境进行全仿真的测试?所有人的回答都是:不可能!当然,我认为这对于数据库是更加不可能的,最大的担心是压测流量产生的数据该如何处理,从来没听说过哪家公司敢在线上系统做压测,万一数据出现问题,这个后果将会非常严重。

我记得在2013年某天一个炎热的下午,我正在库存数据库的问题中焦头烂额的时候,叔同(全链路压测技术负责人)来找我商量全链路压测数据库的技术方案。就在那个下午,我们两个人讨论出了一个“影子表”的方案,即在线上系统中建立一套“影子表”来存储和处理所有的压测数据,并且由系统保证两套表结构的同步。但是,我们对这件事心里都没底,我相信在双11的前几周,没有几个人相信全链路压测能够落地,我们大部分的准备工作还是按照人工review+线下压测的方式进行。但是,经过所有人的努力,这件事竟然在双11前两周取得了突破性进展,当第一次全链路压测成功的时候,所有人都觉得不敢相信。

最后,双11的前几个晚上,几乎每天晚上都会做一轮全链路压测,每个人都乐此不疲,给我留下的印象实在太深刻了。但这个过程,也并不是一帆风顺,我们压出了很多次故障,多次写错了数据,甚至影响了第二天的报表,长时间高压力的压测甚至影响了机器和SSD的寿命。即便出现了如此多的问题,大家依然坚定地往前走,我觉得这就是阿里巴巴与众不同的地方,因为我们相信所以看见。事实也证明,全链路压测变成了双11备战中最有效的大杀器。

如今,全链路压测技术已经成为阿里云上的一个产品,变成了更加普惠的技术服务更多企业。

图片 7

2015年,我从数据库的队长成为整个技术保障部的总队长,负责整个技术设施领域的双11备战工作,包括IDC、网络、硬件、数据库、CDN,应用等所有技术领域,我第一次面对如此多的专业技术领域,对我又是一次全新的挑战。但是,这一次我却被一个新问题难倒了:大屏。

2015年,我们第一次举办天猫双11晚会,这一年晚会和媒体中心第一次不在杭州园区,而是选择在北京水立方,媒体中心全球26小时直播,全球都在关注我们双11当天的盛况,需要北京杭州两地协同作战,困难和挑战可想而知!大家都知道对媒体直播大屏来说最最重要的两个时刻,一个是双11零点开始的时刻,一个是双11二十四点结束的时刻,全程要求媒体直播大屏上跳动的GMV数字尽可能的不延迟,那一年我们为了提升北京水立方现场的体验及和杭州总指挥中心的互动,在零点前有一个倒计时环节,连线杭州光明顶作战指挥室,逍遥子会为大家揭幕2015双11启动,然后直接切换到我们的媒体大屏,所以对GMV数字的要求基本上是零延迟,这个挑战有多大不言而喻!然而,第一次全链路压测时却非常不尽人意,延时在几十秒以上,当时的总指挥振飞坚决的说:GMV第一个数字跳动必须要在5秒内,既要求5秒内就拿到实时的交易数字,又要求这个数字必须是准确的,所有人都觉得这是不可能完成的任务。当时,导演组也提了另外一个预案,可以在双11零点后,先显示一个数字跳动的特效,等我们准备好之后,再切换到真实的交易数字,但对媒体大屏来说所有屏上的数据都必须是真实且正确的(这是阿里人的价值观),所以我们不可能用这个兜底的方案,所有人想的都是如何把延迟做到5秒内,当天晚上,所有相关的团队就成立一个大屏技术攻关组,开始封闭技术攻关,别看一个小小的数字,背后涉及应用和数据库日志的实时计算、存储和展示等全链路所有环节,是真正的跨团队技术攻关,最终不负众望,我们双11零点GMV第一个数字跳动是在3秒,严格控制在5秒内,是非常非常不容易的!不仅如此,为了保证整个大屏展示万无一失,我们做了双链路冗余,类似于飞机双发动机,两条链路同时计算,并可实时切换。

我想大家一定不了解大屏上一个小小的数字,背后还有如此多的故事和技术挑战吧。双11就是如此,由无数小的环节组成,背后凝聚了每个阿里人的付出。

图片 8

做过大规模系统的人都知道,监控系统就如同我们的眼睛一样,如果没有它,系统发生什么状况我们都不知道。我们数据库也有一套监控系统,通过部署在主机上的agent,定期采集主机和数据库的关键指标,包括:CPU和IO利用率,数据库QPS、TPS和响应时间,慢SQL日志等等,并把这些指标存储在数据库中,进行分析和展示,最初这个数据库也是MySQL。

随着阿里巴巴数据库规模越来越大,整个监控系统就成为了瓶颈,比如:采集精度,受限于系统能力,最初我们只能做到1分钟,后来经过历年的优化,我们把采集精度提升到10秒。但是,最让人感到尴尬的是:每一年双11零点前,我们通常都有一个预案:对监控系统进行降级操作,比如降低采集精度,关闭某些监控项等等。这是因为高峰期的压力太大,不得已而为之。

另外一个业务挑战来自安全部,他们对我们提出一个要求,希望能够采集到每一条在数据库上运行的SQL,并能实时送到大数据计算平台进行分析。这个要求对我们更是不可能完成的任务,因为每一个时刻运行的SQL是非常巨大的,通常的做法只能做到采样,现在要求是一条不漏的记录下来,并且能够进行分析,挑战非常大。

2016年双11,我们启动了一个项目:对我们整个监控系统进行了重新设计。目标:具备秒级监控能力和全量SQL的采集计算能力,且双11峰值不降级。第一是要解决海量监控数据的存储和计算问题,我们选择了阿里巴巴自研的时序数据库TSDB,它是专门针对IOT和APM等场景下的海量时序数据而设计的数据库。第二是要解决全量SQL的采集和计算的问题,我们在AliSQL内置了一个实时SQL采集接口,SQL执行后不需要写日志就直接通过消息队列传输到流计算平台上进行实时处理,实现了全量SQL的分析与处理。解决了这两个技术难题后,2016年双11,我们达到了秒级监控和全量SQL采集的业务目标。

后来,这些监控数据和全量SQL成为了一个巨大的待挖掘的宝库,通过对这些数据的分析,并与AI技术相结合,我们推出了CloudDBA数据库智能化诊断引擎。我们相信数据库的未来是Self-drvingdatabase,它有四个特性:自诊断、自优化、自决策和自恢复。如前文所述,目前我们在智能化方向上已经取得了一些进展。

现在,TSDB已经是阿里云上的一个产品,而CloudDBA除了服务阿里巴巴内部数万工程师,也已经在云上为用户提供数据库优化服务。我们不仅吃自己的狗粮,解决自己的问题,同时也用阿里巴巴的场景不断磨练技术,服务更多的云上用户。这就是双11对技术的推动作用。

在双11的历史上,阿里巴巴自研缓存-Tair是非常重要的技术产品,数据库正是因为有了Tair的帮助,才扛起了双11如此巨大的数据访问量。在大规模使用Tair的同时,开发同学也希望数据库可以提供高性能的KV接口,并且通过KV和SQL两个接口查询的数据是一致的,这样可以大大简化业务开发的工作量,X-KV因此因用而生,它是X-DB的KV组件,通过绕过SQL解析的过程,直接访问内存中的数据,可以实现非常高的性能以及比SQL接口低数倍的响应时间。X-KV技术在2016年双11第一次得到了应用,用户反馈非常好,QPS可以做到数十万级别。在2017年双11,我们又做了一个黑科技,通过中间件TDDL自动来实现SQL和KV的转换,开发不再需要同时开发两套接口,只需要用SQL访问数据库,TDDL会自动在后台把SQL自动转换为KV接口,进一步提升了开发的效率,降低了数据库的负载。

图片 9

2016年双11,Tair碰到了一个业界技术难题:热点。大家都知道缓存系统中一个key永远只能分布在一台机器上,但是双11时,热点非常集中,加上访问量非常大,很容易就超出了单机的容量限制,CPU和网卡都会成为瓶颈。由于热点无法预测,可能是流量热点,也可能是频率热点,造成2016年双11我们就像消防队员一样四处灭火,疲于奔命。2017年,Tair团队的同学就在思考如何解决这个业界的技术难题,并且创新性地提出了一种自适应热点的技术方案:第一是智能识别技术, Tair内部采用多级LRU的数据结构,通过将访问数据Key的频率和大小设定不同权值,从而放到不同层级的LRU上,这样淘汰时可以确保权值高的那批Key得到保留。最终保留下来且超过阈值设定的就会判断为热点Key。第二是动态散列技术,当发现热点后,应用服务器和Tair服务端就会联动起来,根据预先设定好的访问模型,将热点数据动态散列到Tair服务端其它数据节点的HotZone存储区域去访问。

图片 10

热点散列技术在2017年双11中取得了非常显著的效果,通过将热点散列到整个集群,所有集群的水位均降低到了安全线下。如果没有这个能力,那么2017年双11很多Tair集群都可能出现问题。

可以看出,数据库和缓存是一对互相依赖的好伙伴,他们互相借鉴,取长补短,共同撑起了双11海量数据存储和访问的一片天。

自从有了全链路压测这项技术后,我们希望每一年双11零点的交易曲线都能如丝般顺滑,但是事情往往不像预期的那样顺利。2016年双11零点后,交易曲线出现了一些波动,才攀逐步升到最高点。事后复盘时,我们发现主要的问题是购物车等数据库在零点的一刹那,由于Buffer pool中的数据是“冷”的,当大量请求在零点一瞬间到来时,数据库需要先“热”起来,需要把数据从SSD读取到Buffer pool中,这就导致瞬间大量请求的响应时间变长,影响了用户的体验。

知道了问题原因后,2017年我们提出了“预热””技术,即在双11前,让各个系统充分“热”起来,包括Tair,数据库,应用等等。为此专门研发了一套预热系统,预热分为数据预热和应用预热两大部分,数据预热包括:数据库和缓存预热,预热系统会模拟应用的访问,通过这种访问将数据加载到缓存和数据库中,保证缓存和数据库BP的命中率。应用预热包括:预建连接和JIT预热,我们会在双11零点前预先建立好数据库连接,防止在高峰时建立连接的开销。同时,因为业务非常复杂,而JAVA代码是解释执行的,如果在高峰时同时做JIT编译,会消耗了大量的CPU,系统响应时间会拉长,通过JIT预热,保证代码可以提前充分编译。

2017年双11,因为系统有了充分的预热,交易曲线在零点时划出了一道完美的曲线。

2017年初,集团高年级技术同学们发起了一个技术讨论:到底要不要做存储计算分离?由此引发了一场扩日持久的大讨论。包括我在王博士的班上课时,针对这个问题也进行了一次技术辩论,由于两方观点势均力敌,最终谁也没有说服谁。对于数据库来说,存储计算分离更加是一个非常敏感的技术话题,大家都知道在IOE时代,小型机和存储之间通过SAN网络连接,本质上就是属于存储计算分离架构。现在我们又要回到这个架构上,是不是技术的倒退?另外,对于数据库来说,IO的响应延时直接影响了数据库的性能,如何解决网络延时的问题?各种各样的问题一直困扰着我们,没有任何结论。

当时,数据库已经可以使用云ECS资源来进行大促弹性扩容,并且已经实现了容器化部署。但是,我们无论如何也无法回避的一个问题就是:如果计算和存储绑定在一起,就无法实现极致的弹性,因为计算节点的迁移必须“搬迁”数据。而且,我们研究了计算和存储的能力的增长曲线,我们发现在双11高峰时,对于计算能力的要求陡增,但是对于存储能力的要求并没有发生显著变化,如果可以实现存储计算分离,双11高峰我们只需要扩容计算节点就可以了。综上所述,存储计算分离是华山一条路,必须搞定。

2017年中,为了验证可行性,我们选择在开源分布式存储Ceph的基础上进行优化,与此同时,阿里巴巴自研高性能分布式存储盘古2.0也在紧锣密鼓的开发中。另外一方面,数据库内核团队也参与其中,通过数据库内核优化减少网络延迟对数据库性能的影响。经过大家的共同努力,最终基于盘古2.0的计算存储分离方案都在2017年双11落地,并且验证了使用离线机头挂载共享存储的弹性方案。经过这次双11,我们证明了数据库存储计算分离是完全可行的。

存储计算分离的成功离不开一位幕后英雄:高性能和低延迟网络,2017年双11我们使用了25G的TCP网络,为了进一步降低延迟,2018年双11我们大规模使用了RDMA技术,大幅度降低了网络延迟,这么大规模的RDMA应用在整个业界都是独一无二的。为了降低IO延迟,我们在文件系统这个环节也做了一个大杀器-DBFS,通过用户态技术,旁路kernel,实现I/O路径的Zero copy。通过这些技术的应用,达到了接近于本存储地的延时和吞吐。

图片 11

2018年双11,随着存储计算分离技术的大规模使用,标志着数据库进入了一个新的时代。

在2012年到2018年的这六年,我见证了零点交易数字的一次次提升,见证了背后数据库技术的一次次突破,更见证了阿里人那种永不言败的精神,每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。

云服务器99元拼团购!拉新还可赢现金红包!300万等你瓜分!马上一键开团赢红包:

本文作者:张瑞

阅读原文

本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。

本文由编程发布,转载请注明来源:新一代数据库技术在双11中的黑科技,阿里数据库