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