简介：钉钉猛增40倍流量压力 阿里云DBA如何应对
1.背景
由于受新型冠状病毒感染的肺炎疫情影响，钉钉流量从春节后开始出现了飞跃性增长。此次疫情流量主要来源于钉钉远程办公和在线教育功能，从字面来看，好像只是钉钉的两个业务功能，但在钉钉内部依赖模块不下20个，主要有消息、视频会议、直播、家校、健康打卡等业务场景。如何保障超过20个业务在如此爆发式增长下的性能和稳定性，是对钉钉后台系统、数据库系统的一个很大挑战。
本文将从数据库DBA的视角来介绍我们是如何打赢这场“战役”的，在这个过程中我们究竟遇到了哪些挑战，我们是如何组织我们的团队，如何思考，如何真正利用技术克服这些挑战，最后通过这场战役，我们又沉淀了哪些经验及技术。
2.对数据库系统的挑战
数据库是钉钉业务系统运行的强依赖，在这种类似双11的场景下，如何规划部署数据库成了稳定性中最重要的一环。但是这次的战役来得突然，并没有很多时间准备，因此面临了非常多的困难与挑战，总结下来有以下3点：
（1）系统所需要的容量是多少，无法预估
以消息模块为例，在春节前，钉钉消息日常流量峰值不到千万，第一次容量评估，大家给2月3号定的目标是日常峰值的3倍。随着2月10号开课高峰的到来，又将2月10号的目标调整为10倍。之后又因为2月17号开学季的到来，再次将目标调整为40倍。所以总容量相比日常峰值翻了40倍！
（2）时间紧，扩容需求众多，资源不足
疫情流量的猛增，给系统带来的冲击不亚于每年的双11。电商会花半年时间准备双11，但这次留给我们的时间只能以小时来计。另一方面，钉钉出于成本的考虑，资源池中基本没有空余的机器，现有的资源部署密度也比较高，如何腾挪资源在较短的时间内为钉钉接近20个核心集群进行扩容是一个很大的问题。
（3）极限场景下如何保障系统稳定性与用户体验
在各种因素制约导致集群无法扩容且系统达已经达到瓶颈时我们能怎么办？有哪些应急手段能用？是否存在一个平衡点，将对用户的影响降到最低？
3.应对措施
3.1人员合理化安排
（1）数据库团队成立疫情期间钉钉业务保障小组
小组成员包含了数据库团队DBA/数据库内核/CORONA/TDDL/DTS/精卫/NOSQL各产品线同学。根据钉钉业务线进行分工，每个DBA跟进一个业务线，参与高峰期的保障，及时播报线上系统状况与水位，让重保决策人员及时了解系统的状况。对线上出现的问题紧急处理，保证问题在短时间内得到修复。对不合理的业务场景进行优化，保证已知问题只出现一次。参与系统的压测，发现潜在风险点及时修正，对系统容量不够的系统进行及时扩容，在资源满足的情况下让数据库在高峰来临之前已经具备足够的容量。
（2）数据库团队与钉钉稳定性团队紧密合作
由于前期资源有限，需要扩容的系统众多，此时钉钉稳定性团队主动站出来帮DBA分担了大量的的压力。他们将数据库的扩容需求根据业务的重要性进行优先级划分，统一扩容需求，DBA根据优先级顺序，结合业务的目标容量进行判断，在有限的资源下有条不紊地进行扩容，保证资源优先用在刀刃上，大大提升了扩容效率。
3.2资源紧急协调
疫情突然爆发，所有人都预期流量会增长，但涨多少很难预估，必须要早作准备。为了保证资源不会成为系统扩容的阻力，DBA和云资源团队进行合理规划，短期内通过借用集团上云的机器，同时缩容其他BU数据库集群，凑出400台左右的机器，保证高优先级系统的扩容需求。同时协调云资源进行搬迁，在短短几天内搬迁了300多台机器到钉钉资源池，保证了钉钉所有数据库的扩容需求。
资源到位后就是检验数据库弹性的时候了，依托于PolarDB-X三节点分布式的部署架构，我们可以较为方便地对原有集群进行在线升级和扩容，对用户影响很低，并且保证数据的一致性。有些场景用户需要从原有集群将数据迁移到分库分表更多的新集群，我们利用DTS搭配成熟的管控平台也能较为流畅地完成。最终可以做到只要有资源，数据库也能具有极致的弹性，满足业务需求。
3.3应急与优化
在系统高峰来临之前，数据库团队内部已经准备好紧急预案：
- 参数降级，调整数据库参数充分发挥数据库能力，提高吞吐
- 资源降级，调整资源限制，CPU隔离放开及数据库BP大小紧急上调
- 针对异常SQL，确认影响后紧急限流，或者通过SQL Execute Plan Profile进行紧急干预
- 全集群流量备库分流，依据压力情况最大可100%读流量切换到备库
- 准备数据库弱一致脚本，在必要时进一步提高数据库吞吐
同时结合业务的限流/降级预案保证了很多数据库系统在未知高峰流量到来时的稳定运行。
但业务限流降低了很多用户的体验，之前业务限流值设置为30QPM/群，表示为每个群在一分钟之内只能发送30条消息，很多时候在1分种的前20s甚至更短时间就已经发出30条消息，在剩下40s以上的时间内用户的体验就是无法使用钉钉。针对这种情况DBA建议减小限流窗口，将限流值30QPM改成30/20S，限流降低了97%，大大改善了用户的体验。
3.4 DB容量预估及性能分析
业务上往往通过集群的CPU情况即可大概分析出系统的水位，但是对DB而言不仅是CPU，IO、网络、SQL、锁等等，任何一个组件的瓶颈往往都会成为最终容量的瓶颈。不同的业务模型，往往瓶颈不一样，即使都是查询量较大的业务，有些可能是CPU的瓶颈，有些可能是内存命中率不够导致的瓶颈，有些则是索引设计不合理导致的瓶颈。更复杂的部分在于，有些瓶颈往往不是线性的，可能压力提升2倍还没什么问题，硬件能力都还有富余，但是提升到3倍就直接崩溃。在这种场景下我们如何比较准确地评估DB的容量呢？
以往我们都是通过经验并和业务方一起进行全链路压测进行DB容量（集群能支撑多少读写）的预估，这种方式有以下几个问题：（1）压测数据集和数据库总量相比往往比较小，DB命中率基本100%，这对于分析有IO的业务模型存在较大误差；（2）成本较大，需要打通上下游整个链路，需较多的人员参与，即使进行全链路压测，真正压到DB端的往往也只是核心的几个接口，无法100%覆盖线上所有的接口，而很多慢SQL往往都来自这些易忽略的接口。
解决这个痛点问题的方法很容易想到——只要把线上的业务流量全部采集下来回放一遍即可，但实现起来是非常复杂的。我们真正需要的其实是针对DB的一种通用的单链路压测能力，并不依赖上游业务，DB层可以自己进行流量的生成、放大或缩小，甚至具备将事务比例更改后再次压测的能力。从2019年开始，在DBA和达摩院数据库实验室科学家们共同的努力下，我们开发了ClouDBench实现了上述的需求，并在此次的战役中帮助DBA进行容量的评估。效果如下图所示：
图1：ClouDBench容量评估效果展示
蓝色是真实业务在某个时刻的性能曲线，绿色是我们采集DB端流量回放出来的性能曲线，可以看出两条曲线在时序上高度拟合，特别是InnoDB内部的指标都非常接近，包括流量的波动。
当我们能够比较真实地回放出业务的workload，我们即可以对压力进行放大，以此来分析DB的容量，并分析出极限场景下的性能瓶颈，从而进行DB的优化及验证优化效果。ClouDBench目前已经在公共云数据库自治服务Database Autonomy Service（DAS）中灰度上线。
4.成果及思考
短短两周内各数据库系统具备了数倍到40倍以上的能力，其中不乏超大型数据库集群，存储空间超过1PB，所有这些都充分证明了阿里云数据库的弹性能力。此次疫情带来的爆发式流量对我们来说是毫无防备的，经历过此役，经验总结下来有以下几点：
4.1人员组织
首先在人员组织上，业务和开发要对突发流量具备敏锐的嗅觉，及时发现提早准备，由业务方稳定性负责人成立应急小组，梳理依赖业务以及对应后台系统，将各业务线owner和后台数据库产品owner纳入应急小组。由应急小组统一容量规划、人力配备以及资源协调，实现业务方、后台产品团队、资源团队联动。
4.2技术架构
在技术架构上，一方面是要使用具有足够弹性的数据库产品，保证使用的数据库产品有自由扩容和缩容的能力，既要保证流量增大后能扩容，也要保证日常流量时可以缩容。管控等各个运维组件需要在实现自动化运维的同时，对于很多关键操作留有应急开关，确保在一些极端场景下，可以较方便地从自动驾驶切换成手动模式，确保任务平稳高效地运行下去。
4.3应急手段
在面对系统瓶劲时，在业务上和数据库产品上都要提前做好预案。在业务上要有降级和限流功能，在系统无法承受压力时，可以降级一部分非核心功能，限制一些次核心功能来保核心业务的正常运行。在数据库产品上需要具有在不扩容的情况下，通过一些优化手段瞬间提升数据库吞吐的能力，更重要的是这些能力需要有较好的兼容性，在不同的部署环境、不同的DB架构下都具有相应的工具和预案。
另一方面，我们需要有评估和检测预案效果的手段，我们现在可以利用ClouDBench对DB进行容量的分析和预测，但是当前的使用成本还是过高，后续ClouDBench需要更加自动化，降低使用成本，将能力透传给业务的owner，在大促之前，自动进行大量的DB单链路压测，评估系统水位，发现性能瓶颈，优化DB参数，验证预案效果。
作者：章左中
阿里云智能数据库产品团队运维专家
阿里巴巴运维专家，从事数据库领域十年以上，先后在甲骨文（中国）、网易等公司任职，在传统行业和互联网行业都有着丰富的经验。目前在阿里云数据库事业部从事专家服务相关工作，擅长数据库优化、架构设计及异构数据库之间的迁移等。
作者：陈荣耀
阿里云智能数据库产品团队运维专家
曾就职于烽火通信任职Oracle DBA，2015年加入阿里，现任阿里云数据库运维专家，有丰富的Oracle、MySQL运维开发经验，擅长数据库故障诊断、性能调优、稳定性建设。目前主要负责数据库性能压测、流量回放（ClouuDBench ）等。
我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。
原文链接：https://developer.aliyun.com/article/771485?
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
转载：https://blog.csdn.net/alitech2017/article/details/113519339