自动化备战、0干预——2016阿里云数据库双11复盘
前言
2016年天猫双11购物狂欢节已经完美落下帷幕，高峰期间订单创建每秒达到了16.5万笔，RDS集群的QPS最高达到了400W，其中99%的商家订单在阿里云云数据库服务中完成存储和处理。这是RDS连续第五年支持天猫双11大促，在持续高压力冲击下，整个双11期0故障0丢单，相比前面四年，我们在备战过程中更加的自动和主动，今年双11高峰期间做达到了0干预的目标。这些都是在前期充分的准备工作中所换来的从容，在面对这么大规模实例备战的时候，通过前几年备战经验的积累，我们在产品自动化上继续深挖，主动推送弹性升级，主动对实例进行健康诊断，主动对集群资源迁移离散，秒级监控大盘等等，通过系统和平台将双11的经验沉淀，为双11的稳定平稳渡过奠定了基础。同时在核心链路组件上不断深入优化，用性能的提升达到了成本的节约。下面分享一下今年双11 备战过程中我们在自动化以及性能优化所作的一些改进。
专家系统主动健康诊断—一千个“DBA”在帮用户
在前面四年双11保障过程中我们发现双11当天往往最容易出现问题是用户自身的应用程序问题导致系统卡慢。双11前没有暴露出的问题，会由于双11当天巨量的订单和高频的系统调用将这些潜在问题放大。提前找出并解决问题是保障双11稳定运行的最佳手段。因此本次双11活动之前，我们就对所有相关数据库进行了全面的体检，将数据库中的潜在风险提前识别出来，并通知用户进行优化和升级。本次双11备战期间我们为客户的实例进行了三轮主动健康诊断，其主要特点：1）诊断报告生成的高度自动化。生成健康诊断报告上万份且全程无人工干预，这一全新的运维方式在之前是不可想象的；2）诊断内容的深度化。从基本的资源使用情况和慢SQL分析，到死锁检测和审计日志全方位统计，再到事务的深层次分析找出应用中的潜在问题等都包含在我们的诊断报告当中；3）运维保障的人性化。本次双11保障不是简单粗暴的让客户升级系统规格，而是以优化为主升级为辅的方式。提前主动给出诊断优化建议极大的提升了用户体验。
Proxy 性能5W到10W的提升
Proxy作为整个RDS数据通道的咽喉，其稳定性是影响整个双11能否成功的关键因素。今年我们双11在 proxy的稳定性及可运维上进行了改进，同时在性能优化上通过减少消息量及数据拷贝使得性能从原来的5w提升到10w，使得在集群不扩容的情况下，承载了去年2倍的压力，相当于减少了一半的机器。通过调整内核参数SO_RCVBUF来提高proxy与client的吞吐量，对于前端网络质量较差的情况吞吐量提升10倍以上。另外，在双11之前通过proxy的容量评估模型发现集群内各分组的压力不均衡问题，从而进行迁移保证了在双11期间各集群及分组压力更加均衡。同时对聚石塔集群的多项重要指标进行秒级大盘化监控，保证能够快速精确的发现系统的潜在问题及容量风险。
秒级监控大盘
打仗行军必须要有可靠，准确和及时的情报信息来支撑瞬息万变的战场。在双11当天，秒级监控大盘能够帮助我们实时关注系统健康状态，分组监控大盘帮助我们关注各个战场运行情况，心中有了运筹于帷幄之中，决胜于千里之外的感觉。
• 每秒更新的集群QPS、流量、延迟、连接数核心指标；
• 全量观察所有Proxy节点关键指标的健康度，秒级发现健康情况变差的节点；
为了能够提前发现Proxy的异常并抓住具体的异常点，我们需要在一个页面上查看多项关键指标在每台Proxy上的健康状况，前端设计上通过热力图的形式来展示，通过精心选择的颜色来标示这个指标的健康情况，多个指标通过tab的方式自动切换。
我们首先需要以最低的损耗全量纪录用户请求的信息，我们在内核TCP协议栈状态机中将每个SQL请求的流量、网络延迟、处理延迟等指标计算出来，并通过内存将数据传到用户态。为了减少发送数据的网络损耗, 首先会在本地进行预处理聚合, 压缩后发送到Kafka集群, 后面用JStorm对不同机器来源的数据进行实时分析。
为了前端的流畅，减少渲染开销，实时趋势图只在页面渲染的时候整条线绘制一次，后面每秒的增量都只做累加绘制；热力图也只在页面渲染的时候才会绘制节点结构，而后面的状态数据更新也只是更改各节点的颜色属性，且五个指标数据共用一个节点结构。
我们在各个环节都做了容错处理，在计算任务上可以出现失败后补回数据，存储上使用RDS作为保障，多节点数据API，前端页面在访问后端出现问题时仔细的处理了异常，保证浏览器页面不崩溃，并在异常恢复后，补回数据继续实时更新。
主动推送弹性升级
弹性升级是商家在双11备战过程比不可少的一个环节，但是每年还是有很多用户不知道是否需要对数据库进行弹性升级。常常看到双11当天还有较多商家进行升级，这个时候其实已经比较危险了，这个时候系统压力往往非常大，对弹性升级的任务是有较大影响的。所以在2016年的双11备战前期，我们的系统能不能够针对用户的系统压力分析，提前通知用户进行升级，这样对双11的平稳渡过有着重要的意义。今年双11期间，通过扫描实例资源使用情况推动客户升级数占总升级的90%。
移山资源自动打散—让资源流动起来
底层物理资源的稳定和均衡是保障双十一稳定运行的基础，双十一之前我们自动将集群的主机根据负载情况进行自动的离散，最大化的利用集群的计算资源，同时也保障在双11期间没有资源使用没过载的主机出现。双十一备战期间，通过系统共下发离散迁移任务超过1000+次，充分有效地利用了线上资源，为双十一的稳定做出了巨大贡献。双11结束之后，移山可以方向进行资源搜索，将双11扩容的资源再次回收到资源池中，以供其他业务进行售卖，已达到资源的最大化使用。
Proxy链路-防闪断，防攻击
然后有人可能会问这些后台的资源离散任务是如何做到对用户的访问实现无影响的？其核心的技术就是在代理层对用户连接上的处理--proxy防闪断。通过协议级解析及SQL parse两层逻辑来判断用户的连接请求状态，对于“空闲”的连接通过proxy来完成切换，连接到新的主库地址，并且对用户无感知。对于非空闲比如事务，我们会等待事务结束再进行切换，尽量的减少切换对用户的连接的影响，通过线上的数据我们行到我们防闪断桥接率达到93%。
Proxy除了连接防闪断能力外，还具有防攻击能力。由于所有的应用请求都经过proxy处理，所以我们在proxy层加入了SQL拦截规则，对于符合注入规则的请求我们可以进行拦截，保护用户数据库的安全。
双11当天问题
通过前期大量的备战工作准备，双11高峰期间我们没有对系统做过任何的干预措施，但收到部分用户反馈的一些典型问题，下面总结如下：
弹性升级任务时间较长
用户的弹性升级过程可能有两类，一类是本机升级，另外一类是跨机升级。本机升级的时间受限于实例本身的压力，如果数据库压力过高可能会导致备库无法完全与主库同步，进而导致升级时间较长；跨机升级的时间除了受限于实例自身的压力外，还与实例的数据量大小相关，具体可以参考文章“高人自有妙计：罗龙九六招制服云数据库大流量峰值”。
用户自身问题导致系统卡慢
双11期间较多客户反馈应用不能响应或rt较长，通过排查定位绝大多数情况是数据库响应请求很快，但是瓶颈在自身的系统设计缺陷以及应用服务器问题，比如DNS请求访问缓慢，或者表结构设计不当，索引缺失等问题。
表结构：
order(
IDint(10) unsigned NOT NULL AUTO_INCREMENT,
Novarchar(50) NOT NULL DEFAULT '',
Fromvarchar(50) DEFAULT NULL,
Shopvarchar(50) DEFAULT NULL,
Codevarchar(50) NOT NULL DEFAULT '',
Flgint(11) DEFAULT '0',
PRIMARY KEY (ID,No,Code`)
) ENGINE=InnoDB AUTO_INCREMENT=176667 DEFAULT CHARSET=utf8
访问SQL：
update order set Flg = '1', No = '11' WHERE No = '11' AND Code='22' and Flg='0'
优化建议：
alter table order add index ind_orderdetail(No)
双11的全民化
随着双11的全民化，有许多企业公司也开始做双11促销，但是他们的经验往往是比较匮乏的。双11当天我们就收到了一些用户的援助请求，由于前期没有做好系统压测，导致在双十一当天业务高峰来临的时候系统垮掉，然后才考虑扩容，这个时候往往已经为时已晚。双11的护航保障经验是可以更广的传播到这些公共云客户上，这也是为什么会写这篇文章的主要原因。
未来，沉淀专家经验到系统中和传承保障经验
双11是全民的双11，云计算是全民的云计算，我们忠心希望未来用户在使用云计算的时候能够像使用水电煤一样简单。我们也会不断地将最佳实践和双11的保障经验沉淀到专家系统中，只有这样才能将其作用最大化，规模化，可复制化，让用户真正简单方便的得到实惠。