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数据同步、跨Region容灾,保证金融级的数据质量服务。

X-DB为了降低用户的迁移和学习成本,选择了兼容成熟的MySQL生态,并且做到了真正100%兼容MySQL生态,为业务,为传统数据库赋能。基于MySQL的业务可以无缝从MySQL迁移到X-DB上来,不需要任何评估和兼容测试,完全零成本迁移。基于MySQL的周边工具平台,甚至是MySQL DBA都可以非常平滑的转移到X-DB上来。阿里内部从今年6月初第一个业务应用灰度切流,到目前为止5个月的时间里,X-DB已覆盖了阿里集团及多个关联公司旗下的多个事业群,为海量的线上业务提供服务,整个过程绝大部分业务都是无感知的。

X-DB拥有真正的跨Region/跨国的数据强一致能力,并已得到实践的检验。双11前夕,核心物流系统、核心IM系统首次完成了中心Region所有数据库不可用的“中心城市容灾演练”,验证业务拥有在整个中心Region均不可用情况下,X-DB和应用仍可以正常提供服务的能力,并保证数据零丢失。

X-DB的核心优势和技术解析

X-DB是阿里自研的全球级分布式关系型数据库。现在业界各种类型的分布式数据库不断涌现,互联网巨头、传统数据库厂商、数据库创业公司都在不断跟进。那么X-DB到底有什么优势能战胜这些竞品,快速获得业务价值呢?

X-DB生态100%兼容MySQL

新一代分布式关系型数据库是对传统关系型数据库的传承和革新。分布式数据库虽然在高可能、强一致、高性能、低成本、高伸缩等多个方面作出了划时代的变革;但其依旧传承了传统数据库强大的SQL接口,系统管理能力。NoSQL的衰弱和NewSQL的兴起,恰恰证明了这一点。一个新的分布式数据库,如果没有传承,自建一个新的生态,将会极大的提高用户的学习和使用成本,整个工具和支持配套也将面临很大的困难。

因此,X-DB作为一个新一代分布式关系型数据库,设计之初就选了业界相对开放和成熟的MySQL开源生态作为自己的基础。这样不单可以让MySQL生态中的用户零成本的切换到X-DB中,快速赋予业务分布式数据库所带来的多种能力;同时可以让MySQL生态中的各种周边工具和DBA等生态的参与者平滑的切换到分布式时代,赋予其支撑分布式数据库的能力。

事实证明X-DB选择的这条路是正确的。在阿里集团及生态下的子公司内部,X-DB在短短的几个月内、在非常少的人力参与下,迅速的完成了对大量传统MySQL/AliSQL集群的换代升级,使得阿里数据库整体进入了分布式时代,整个过程业务几乎零参与。同时X-DB对MySQL生态下的运维系统/工具、知识体系也实现了兼容,整个MySQL时代的支撑平台,支撑人员都可以平滑的过度到分布式数据库时代,拥有了支撑下一代数据库的能力,这个是非常难得的。

跨Region/全球强同步能力

业界支持分布式强一致的数据库很多,但是其强一致都是有范围的,有些支持AZ内强一致,有些支持跨AZ强一致,真正能做到跨Region/跨国强一致的却是凤毛麟角。目前业界主流数据库中,只有Spanner宣称自己是Global Distribution,包括Amazon
Aurora在内的其他主流数据库目前都不支持跨Region的强一致。X-DB是真正做到了跨Region/跨国强一致的分布式数据库,并且在业务上得到了验证。今年音视频服务全站迁移X-DB,同时X-DB支撑了音视频服务国际化等多个国际化项目,实现跨国部署。包括核心交易系统、核心物流系统、核心IM系统在内的大量业务集群以跨Region强同步模式部署,使得业务拥有了城市级容灾情况下,数据零丢失,服务秒级恢复的能力。核心物流系统、核心IM系统在双11前夕分别进行了中心Region全不可用的容灾演练,X-DB在15秒内自动完成跨Region的重新激活,数据零丢失,这在整个行业都是先行者。

技术解析:X-Paxos——高性能Paxos独立库

Paxos是一种分布式一致性算法,其最基础也是最重要的功能是保证分布式系统中多个节点的数据(日志)的强一致,它是分布式系统的基石。虽然Paxos算法被图灵奖获得者Leslie Lamport首次提出到现在已经19年了,离第一个工业实现(Chubby)也已经11年了,但是近几年,顶级会议/业内文章中Paxos的优化和讨论还是非常的多,而且到目前为止真正工业级的、高性能的、高可扩展的Paxos算法库还是非常的少见。

X-Paoxs是阿里独立设计/研发的,真正工业级的Paxos独立库,其在性能上好于业界对手1、2个数量级以上,同时其强大的扩展性和完善的生态系统都是竞品所没有的,X-Paxos为分布式高性能数据库X-DB奠定了坚实的基础。

X-Paxos从基础架构,到网络模型,再到算法本身都有大量的创新:

  • 基于SEDA架构的异步并发调度框架
    由于Paxos的内部状态复杂,实现高效的单实例多线程的Paxos变成一个非常大的挑战。大部分竞品例如Oracle/MySQL的Group Replication等针对单个Paxos对象都是单线程实现。X-Paxos实现了一整套高效的异步并发调度框架,并基于SEDA(Staged Event-Driven Architecture)思想,对整个Paxos协议进行了并发切分和实现,采用了大量无锁设计;由异步并发调度框架进行调度和执行,充分利用多核资源,实现高性能。
  • 基于Batching & Pipelining的网络优化
    跨Region/跨国场景下对X-Paxos来说最大的挑战就是如何在高延迟网络下保持高吞吐和相对低延迟,X-Paxos针对高延迟网络做了大量的协议优化尝试和测试,并结合学术界现有的理论成果通过合理的Batching和Pipelining,设计并实现了一整套自适应的针对高延迟高吞吐和低延迟高吞吐网络的通信模式,极大的提升了X-Paxos的性能。类似的优化大部分还在理论阶段,在同类竞品中还非常的罕见。

  • Jepsen/TLA+的分布式原理/实现验证
    《Paxos made live》中有过一个说法,证明一个Paxos实现是正确的,比实现这个Paxos本身会更难。因此我们在设计和实现X-Paxos的时候,投入了大量的精力在Paxos的原理证明了实现验证上。我们用TLA+对X-Paxos进行建模,验证其理论正确性。我们将Jepsen对X-Paxos/X-DB进行适配,同时增加了大量的验证Case和注入错误,7X24小时运行,验证其实现正确性。

强一致下的高性能

业界习惯性的认为,强一致一定会带来性能的下降,开强MP的Oracle,在Semi-Sync的MySQL,MySQL Group Replication甚至于跨Region部署以后的Spanner,会面临大幅度的性能下降的问题。

今年双11 X-DB在核心交易系统、核心物流系统等交易核心链路上100%切流,经历了多轮全链路压测和双11零点业务32.5万笔/秒,数据库SQL上亿次/秒的峰值的性能考验,证明了X-DB完全有能力实现强一致和高性能的鱼熊兼得。

X-DB从Paxos协议的实现,到X-Paxos和AliSQL的日志结合,再到AliSQL本身的提交逻辑,锁策略都做了大量的优化。保证X-DB无论是在多机房部署还是多Region部署下,都能保证性能和单节点模式(非强一致)下无大幅度劣化。特别是在跨Region部署时,和其他分布式数据库相比,优势尤为明显。这也是业务能够接受X-DB跨Region部署的主要原因。

X-DB是AliSQL和X-Paxos的紧密结合而产生的。高性能的X-Paxos为不单为X-DB带来了高可用和强一致的能力,同时为X-DB的在强一致下的高可用奠定了坚实的基础。除此以外,我们在AliSQL和X-Paxos的结合上也做了大量的优化,例如一体化日志设计和异步事务提交。

技术解析:一体化日志设计

X-DB的Consensus日志采用了单一事务日志的方案(区别于MySQL的binlog和relay_log两份日志),单一事务日志格式MySQL binlog的事务日志格式。这份日志被用于集群节点间数据的同步以及下游应用的消费。

一体化日志设计带来的好处是显而易见的,首先是日志量的减少。MySQL接收到主库的网络消息后会先本地落一份relay_log日志,在消费后再产生一份binlog日志。虽然relay_log会很快被回收,但是日志的写入量是实实在在的两份。反观X-DB在统一了日志后,同一个事务在一个实例节点上只需要记录一份日志。其次统一日志能够让日志真正按照产生的先后续做到逻辑和物理上的一致,这对于日志的检索效率来说是大有裨益的。首先是顺序扫描日志的时候可以做到物理IO上的顺序性,其次Paxos算法的运转对于日志的检索和获取都有较高的要求,如果检索一份日志需要先后扫描两份日志跳转来判断比较,那对于效率来说是非常低下的。

技术解析:异步事务提交

在数据库中,服务端的线程池是非常有效降低线程上下文切换开销,提升系统吞吐的技术。但是在跨城/跨国环境下,巨大的网络延迟使得线程池本身会成为一种瓶颈。例如X-DB集群的节点分布在网络RTT达到几十毫秒级别的两个Region中,那么在实际的运行中会发现线程池中绝大部份线程都在等待日志跨Region同步回包,而客户端的请求就没有足够的线程去处理了,这其实造成了服务器资源的严重浪费。

重新回到非线程池的状态不是一个明智之举,既要低上下文开销又要有高资源利用率。我们采取的解决方案是将事务处理中可能最为费时的等待事务日志回报做成异步化。 这样就把一个完整的事务流程拆成了:处理请求->等待同步->事务提交的三个步骤,
三个步骤可以分别由线程池的不同线程来完成。每个步骤X-DB可以精确控制并发量,例如可以用最少的线程数量来处理事务等待日志同步的工作,用大量的线程来处理事务提交等等。在异步化改造后,只要用户的并发请求量足够多,系统吞吐量上可以有明显的提高。

丰富灵活的部署模式

针对电商双11这种,不同时期不同需求的业务模型,X-DB提供了非常丰富并且灵活的部署模式,例如核心交易系统、核心物流系统,在今年双11前夕,将部署模式从跨城强同步模式一键切换回同城强同步模式,并动态调整拓扑,在保证机房级强一致的前提下,有效的降低了RT,提升了吞吐。

集团内外不同的业务对数据库的部署需求各不相同,为了更广泛的支持不同的业务X-DB支持的部署模式非常的灵活。业务可以根据自己的容灾和业务需求,在不同的部署范围内(同城多机房/国内多Region/跨国等)选择任意数量、任意角色的节点进行部署,节点的部署和角色同样可以在线修改以适应业务的不同时期的不同需求,例如双11。这样说有点抽象,这里举2个实际的案例

案例:同城跨机房模式


上图是一个经典的同城跨机房强同步方案,满足以下需求

  • 机房级容灾数据零丢失,10秒级容灾切换
  • 相对于主备方案零成本增加(2数据副本,1日志副本,日志副本资源需求可忽略)
  • RPO < 1S(通过X-Paxos SDK持续备份)
    当然业务可以在这个模式的基础上做多种扩展,例如增加只读无选举权的learner节点;增加有选举权的follower节点等来提升容灾等级和读能力。

案例:跨城单元化模式


上图是一个经典的跨城强同步方案,满足以下需求

  • 真正的跨城强一致能力:任意城市整体不可用不影响集群可用性,零数据丢失
  • 高性能:在跨城强同步下依然保持高性能
  • 灵活的切换策略:可分别设置同城节点,跨城节点切换优先级
  • 高伸缩能力:可任意增加/删除/动态修改任意Region的数量和角色
    目前核心交易系统、核心物流系统、核心IM系统等核心集群均采用类似部署方案保证跨城容灾能力。

更重要的是X-DB支持动态切换部署模式,例如核心交易系统、核心物流系统等集群在双11期间一键动态将跨城模式切换到同城模式,在保持机房级容灾能力的前提下,获得更高的性能;音视频服务通过在海外Region动态扩展一个Leaner角色的节点实现国际化。

技术解析:Paxos框架下的角色定制和动态变更

在分布式数据库中经典的Paxos用法是将Paxos作为一个整体来解决高可用和强一致问题。然而Paxos算法不单单能解决高可用强一致问题。在X-Paxos中我们对Paxos算法进行了扩展,将Paxos算法中节点的三个角色(Proposer/Accepter/Learner)进行了剥离和重组,形成了多种不同角色的节点,这些节点组合后,可以形成多种适合不同业务的部署模式,同时X-Paxos设计了一整套动态Configure Change算法支持所有部署模式之间的动态切换,对业务非常友好。

X-DB的演进

X-DB 1.0是整个X-DB的计划的一部分,整个X-DB计划将按照三步进行

  1. X-DB 1.0(X-Cluster): 集成X-Paxos,实现金融级分布式强一致能力、一体化的架构设计以及统一的生态环境。
  2. X-DB 2.0: 基于自研高性能低成本存储引擎X-Engine,与分布式存储结合打造的计算与存储分离架构,能独立扩展计算和存储的能力,为业务在不同场景的负载下,提供灵活的伸缩能力。同时得益于全新设计的存储引擎,能够提供其他同类产品难以匹敌的性能。
  3. X-DB 3.0: 新一代分布式关系型数据库,同时支持了数据自动分片负载均衡,多点可读可写,跨域强同步,AZ内快速扩充计算节点的计算存储分离架构,应用了一系列技术:为充分发挥硬件性能的软硬件结合技术以及根据数据冷热特点的分层混合存储技术,无论上是在扩展性和高可用性,还是成本和性能上都做到极致,是X-DB计划数据库系统演进的最终形态。
时间: 2024-07-30 18:11:14

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

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

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

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

作者:吕建枢(吕健) 背景 随着阿里集团电商.物流.大文娱等业务的蓬勃发展,数据库实例以及数据存储规模不断增长,在传统基于单机的运维以及管理模式下,遇到非常多的困难与挑战,主要归结为: 机型采购与预算问题在单机模式下计算资源(CPU和内存)与存储资源(主要为磁盘或者SSD)存在着不可调和的冲突:计算与存储资源绑定紧密,无法进行单独预算.数据库存储时,要么计算资源达到瓶颈,要么是存储单机存储容量不足.这种绑定模式下,注定了有一种资源必须是浪费的. 调度效率问题在计算与存储绑定的情况下,计算资源无法

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

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

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

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

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

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

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

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

【双11背后的技术】集团AliDocker化双11总结

选自<不一样的技术创新--阿里巴巴2016双11背后的技术>,全书目录:https://yq.aliyun.com/articles/68637 本文作者: 林轩.白慕.潇谦  前言     在基础设施方面,今年双11最大的变化是支撑双11的所有交易核心应用都跑在了Docker容器中.几十万Docker容器撑起了双11交易17.5万笔每秒的下单峰值.众所周知Docker技术这几年大热,但如果期望阿里这么大体量的应用全部使用Docker,这可不是一朝一夕就能完成的事情.阿里的应用数量庞大,种类众

使用双缓冲技术绘制曲线图

当数据量很大时,绘图可能需要几秒钟甚至更长的时间,而且有时还会出现闪烁现象,为了解决这些问题,可采用双缓冲技术来绘制曲线图. 双缓冲即在内存中创建一个与屏幕绘图区域一致的对象,先将图形绘制到内存中的这个对象上,再一次性将这个对象上的图形拷贝到屏幕上,这样能大大加快绘图的速度.双缓冲实现过程如下: 1.在内存中创建与画布一致的缓冲区 BufferBmp=new Graphics::TBitmap(); BufferBmp->Canvas->Handle=CreateCompatibleDC(Ca

Android采用双缓冲技术实现画板_Android

本文实例为大家分享了Android实现画板的具体代码,采用的技术是双缓冲技术,供大家参考,具体内容如下 1.双缓冲技术的概念 所谓的双缓冲技术其实很简单,当程序需要在指定的View上进行绘制时,程序并不需要直接绘制到该View组件,而是先绘制到一个内存中的Bitmap图片上(就是缓冲),等内存中的Bitmap绘制好之后,再一次性将Bitmap绘制到View组件上. 2.Android采用双缓冲实现画板  实现的思路: 1).定义一个内存中图片,将他作为缓冲区Bitmap cacheBitmap