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

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

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

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

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

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

　　一、2012，肩挑背扛与逐个优化

　　阿里云数据库支撑双11天猫商家后台核心数据库的第一年是2012年。它承担了天猫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年要重点把数据链路中间层稳定下来。这一年中，我们挑战很大，经验也得到很多：

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

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

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

　　三、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的建议得到了很好的解决：

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

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

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

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

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

　　五、未来，走出去传承最佳实践和保障经验

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

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

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

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

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