从肩挑背扛到99%聚石塔订单，四年里AliCloudDB双11技术突破

　　摘要：2015年天猫双11购物狂欢节已经完美结束，在高峰期间订单创建每秒达到了14万笔(达每秒14万笔)，总订单量达到了4.78亿，技术指标再次刷新世界纪录。其中99%的订单通过聚石塔订单推送，并在阿里云云数据库服务(AliCloudDB，曾称RDS)中完成存储和处理。在持续高压力冲击下，整个双11期...

　　2015年天猫双11购物狂欢节已经完美落下帷幕，高峰期间订单创建每秒达到了14万笔(达每秒14万笔)，总订单量达到了4.78亿，技术指标再次刷新世界纪录。其中99%的订单通过聚石塔订单推送，并在阿里云云数据库服务(AliCloudDB，曾称RDS)中完成存储和处理。在持续高压力冲击下，整个双11期间AliCloudDB表现坚如磐石：

　　高峰期间集群的总QPS达到了近300W每秒;

　　单个商家最高处理订单的能力超过400万单;

　　百万商家在AliCloudDB上稳定运行，全网实现了0故障，0丢单。

　　在华丽数字的背后，作为整个天猫商家后台数据库的基石，AliCloudDB是如何保障在零点洪峰来临时候稳定、安全和顺畅?如此庞大规模的数据库实例集群又是怎样一步步成长起来的?“云栖社区”特别邀请连续4年支持天猫双11的AliCloudDB团队核心专家玄惭，深入分享这4年双11背后的AliCloudDB是如何实现技术突破的。

　　以下为玄惭的分享：

　　下图为：天猫双11背后的“护航侠”——阿里云数据库

　　2012年：肩挑背扛与逐个优化

　　2012年是阿里云数据库支撑双11天猫商家后台核心数据库的第一年。它承担了天猫20%的订单量。如果要用一个关键词来形容2012年的双11，那就是肩挑背扛了。阿里云数据库从9月份开始对外提供服务之后，有很多商家就选择将本地数据库迁移上云。但是在迁移过程中，遇到了一个非常大的问题，当时阿里云数据库支持MySQL和SQLSERVER两类引擎。这两类数据库的上云迁移都不支持在线，从而导致用户的业务停机时间(会)非常长。同时迁移过程很容易受网络影响而出现中断。该问题在SQLSERVER上尤为突出。记得有一个用户由于数据量特别大，为了加快迁移速度，他甚至把硬盘邮寄给了我们。所以帮助用户迁移数据库上云的工作就会落到了DBA身上。那个时候，阿里云数据库短短一个月内帮助用户手工迁移了数百规模的数据库实例到云上。

　　但是现在这个问题已经不再存在。数据库迁移已经通过DTS在线迁移工具来完成数据库上云的迁移工作，从而以最大程度地降低业务停机时间。除了数据迁移，DTS目前还支持数据订阅及数据实时同步。底层使用数据流基础设施为阿里双11异地双活基础架构，为数千下游应用提供实时数据流，已在线上稳定运行达3年之久。使用DTS可以轻松帮助云用户构建安全、可扩展、高可用的数据架构。

　　但是谈到2012年双11备战，记忆犹新。双11的前一个月，阿里云数据库团队白天要准备资源和双11所有工作，晚上还需要协助用户将数据库迁移上云。弹性升级需要对实例逐个进行升级，商家的数据库也需要逐个进行优化，并为商家提出优化建议。天猫双11能否扛过零点高峰?我的心里是打鼓的，但结果让我们深受鼓舞。完全OK。而后几年，我们不断打磨产品，沉淀出了众多的产品需求：例如上云迁移，资源自动扩容，收容和离散，性能诊断自动化等。在我们看来，只有把双11的经验和能力产品化，才是真正长远发展之计。

　　2013年：指数增长与数据链路改造迁移

　　2013年是阿里云数据库支撑双11商家后台核心数据库的第二年。它承担了天猫50%的订单量。如果用一个关键词来形容2013年的双11，那就是变化。第一年双11实例规模量不是很大，然而2013年的双11实例数规模则是成指数级别增长。原来的数据访问链路层的容量已经不能再支持如此规模的用户量。所以我们开始对数据链路访问层进行改造迁移。改造迁移过程的时间点与双11的备战时间点重合，从而触发了非常多的变化，给双11的备战工作造成了很大的压力。一路拼搏，终于在双11之前把链路架构稳定下来。在双11当天，记忆尤深的是下午6点左右出现的惊心动魄的场面。由于一个用户发送了超大长度的SQL到阿里云数据库，同时由于Proxy本身问题，使整个proxy集群出现异常。虽然问题很快得到了处理，影响可控，但是也给我们敲响了警钟——2014年要重点把数据链路中间层稳定下来。这一年中，我们挑战很大，经验也得到很多：

　　SQLSERVER支持备份文件FTP导入，解决了2012用户上云的问题;

　　全链路压测引入RDS双11，检验RDS各个组件容量，从中发现问题并解决。

　　实现了IO，CPU的资源隔离，解决了大部分实例间资源争抢问题;

　　2014年：注入拦截保证安全与数据库优化

　　2014年的双11，阿里云数据库在经历了两年的成长期之后开始迎来成熟。汲取了2013年数据链路改造的惨痛教训，我们在双11前统一了所有集群的数据链路访问。在支持灵活数据链路访问模式，高安全链路访问模式下，实现了SQL注入的拦截功能，帮助用户更简单地防护数据库的安全，避免数据库被注入攻破。双11当天表现平稳。承担了天猫96%的订单量。集群QPS峰值达到142W。集群RDS实例数也达到了历史新高。

　　2014年双11，虽然系统已经趋于稳定，但是人工参与度依然比较高。团队投入了较多的人力资源来帮助商家的数据库进行优化。同时双11扩容的资源并没有完全下线，也造成了部分集群资源的空闲。所以这两个问题抛给了2015年双11。

　　2015年：资源自动离散与收容和自动化诊断

　　2015年集群的规模越来越大，双11我们为集群预备了2-3倍容量资源供用户弹性升级使用。为了使新上线的机器得到资源最大化利用，从而保障系统的稳定，我们需要将老机器上的实例离散到新机器上。同时双11活动完后我们需要把这一批扩容的主机下线，然后将其补充到其他业务集群进行售卖，从而实现资源利用率最大化。针对上面的两个应用场景，RDS启动了移山项目。移山离散策略着力于对主机以及实例最近的性能数据进行计算，得出需要迁移离散的实例列表。移山收容策略则对集群和主机的性能数据进行计算，进而得出需要收容的主机实例列表。

　　在双11期间，移山共完成了数千次的资源离散任务，极大程度上节约了人力成本，为双11的资源稳定奠定了坚实基础。双11后我们快速下线掉扩容的机器资源，补充到其他业务集群继续售卖。这实现了资源最大化利用，使资源真正地“流动”起来了。

　　在以前的双11备战期间，云DBA团队需要投入大量的人力对商家的数据库进行优化。但是随着实例规模数的上涨，这种人工的支持方式显然是不可持续的。在2015年，我们不断将云DBA的诊断优化经验进行总结归纳，并开发完成了CloudDBA诊断引擎。这个诊断工具在今年双11带来了极大的生产力解放。大量客户的性能问题通过CloudDBA的建议得到了很好的解决：

　　压测期间，用户共触发210次性能诊断任务，产生2546条优化建议;

　　经过多轮索引推荐算法优化，并引入代价模型，语句重写等技术后，MySQL索引推荐准确率超过90%;

　　双11期间，CloudDBA诊断引擎服务所有的RDS实例，共产生优化建议37713条;

　　目前CloudDBA诊断引擎支持索引推荐、空间诊断、只读实例延迟诊断等功能。RDS的用户可以在阿里云控制台、DMS上获取诊断信息。目前已经有不少云用户学会了如何通过诊断引擎进行自动优化，使SQL诊断不再成为难事。

　　除此以外，还有异地灾备的产品化也非常值得分享的。2015年RDS为天猫的商家后台数据库提供了异地灾备的功能。当主机房出现较大的负载压力、断网、断电等极端情况，RDS可将商家的后台系统在30分钟内切换至灾备机房继续运行，从而保障总体可靠性，进一步确保平台大型品牌商家双11期间后台系统安全、稳定。今年双11当天出现了一个小插曲恰好用到了这些。一家大型商家的数据库出现了性能抖动，是由于后台的订单报表系统极其复杂的SQL拖垮了主库的性能。SQL出现堆积，CPU达到100%。此时优化SQL的效果非常有限。我们想到了异地灾备节点。灾备节点的数据同步和主库基本是实时的。所以当时我们就建议用户将这个订单报表系统切换到灾备实例上去查询数据，以此来减小主库的压力。这个方法很成功。

　　未来：走出去传承最佳实践与保障经验

　　还记得2012年一家天猫服务商和我说：“今年遇到了一群靠谱的人，在加上靠谱的技术，才能够一起做靠谱的事情。”这句话一直激励着我。我们也相信，能够真正地帮到商家，是对这次参与双11所有人的最大回报。

　　从资源手工离散和下线到自动化扩容和收容，让资源真正流动起来;

　　从上云肩挑背扛到在线迁移，让上云不再成为难事;

　　将诊断经验沉淀为自动化诊断工具，让诊断不再成为难事。

　　这一幕又一幕，我们始终坚信只有把双11的经验和能力产品化和工具化，利用双11这样极具挑战的项目不断锤炼我们的产品，才是真正长远发展之计。历经4年发展，AliCloudDB在稳定性以及产品功能的丰富上不断进步。在未来，我们希望能够出去多走一走，接近云用户，多多倾听他们的声音，将最佳实践和保障经验传承给用户，帮助他们一起把系统稳定性保障起来，这将是我们最大的心愿。