本文作者：阿里云数据库运维专家笺一、奕信
很近，由于受新型冠状病毒感染的肺炎疫情影响，钉钉流量出现了飞跃性增长。
自2月3日以来，钉钉持续迎来流量高峰：远超1000万家企业使用钉钉在线办公，总人数超过2亿；全国20多个省份200多个教育局启动了“课程直播”计划，涉及2万多个中小学在内的1200多万的学生。
持续的业务增长也让钉钉出现了很多历史性时刻：
2月5日钉钉跃居苹果免费AppStore排行榜第一，霸占至今
2月6号钉钉上了中心电视台，钉钉CTO接受采访
此次疫情流量主要来源于钉钉远程办公和在线教育功能，从字面来看，似乎只是钉钉的两个业务功能，但在钉钉内部依靠模块不下20个，主要有在消息/视频会议/直播/家校/健康打卡等业务场景。如何保障超过20个业务在如此爆发式增长下的性能和稳定性，是对钉钉后台系统、数据库系统的一个很大挑战。
本文会从数据库DBA的视角来介绍下我们是如何打赢这场“战争”的，在这个过程中我们究竟碰到了哪些挑战，我们是如何组织我们的团队，如何思考，如何真正利用技术克服这些挑战，很后通过这场战争，我们又沉淀了哪些经验及技术。
数据库是钉钉业务系统运行的强依靠，在这种类似双11的场景下，如何规划部署数据库成了稳定性中很重要的一环，但是这次的战争来的太忽然，我们并没有很多时间预备，因此我们面临了非常多的困难与挑战，总结下来有以下3点：
1、系统所需要的容量是多少，无法预估
以消息模块为例，在春节前，钉钉消息日常流量峰值不到千万，第一次容量评估，大家给2月3号定了个目标是日常峰值的3倍，随着2月10号开课高峰的到来，又将2月10号的目标调整为10倍，之后又因为2月17号开学季的到来，再次将目标调整为40倍。所以总容量相比日常峰值，翻了40倍！
2、时间紧，扩容需求众多，资源不足
疫情流量的猛增，给系统带来的冲击不亚于每年的双11。电商会花半年时间预备双11，但这次留给我们的时间只能以小时来计。另一方面，钉钉出于成本的考虑，资源池中基本没有空余的机器，现有的资源部署密度也比较高，如何腾挪资源在较短的时间内为钉钉接近20个核心集群进行扩容是一个很大的问题。
3、极限场景下如何保障系统稳定性与用户体验
在各种因素制约导致集群无法扩容且系统达已经达到瓶颈时我们能怎么办？有哪些应急手段能用?是否存在一个平衡点，将对用户的影响降到很低？
忽然间猛增的业务流量也是对钉钉底层数据库系统，数据库团队的一次全面检验。依托于底层成熟的管控，DTS，中间件系统，数据库团队和钉钉业务团队紧密合作，通过专业的能力和成熟的产品将上述挑战一一化解。
1、人员合理化安排
小组成员包含了数据库团队DBA/数据库内核/CORONA/TDDL/DTS/精卫/NOSQL各产品线同学。
根据钉钉业务线进行分工，每个DBA跟进一个业务线，参与高峰期的保障，及时播报线上系统状况与水位，让重保决策人员及时了解系统的状况。对线上出现的问题紧急处理，保证问题在短时间内得到修复。对不合理的业务场景进行优化，保证已知问题只出现一次。参与系统的压测，发现潜在风险点及时修正，对系统容量不够的系统进行及时扩容，在资源满足的情况下让数据库在高峰来临之前已经具备足够的容量。
由于前期资源有限，需要扩容的系统众多，每个业务线owner都觉得自己的系统是很重要的，必须要优先扩容自己的数据库，甚至有些owner拉自己的领导更甚至领导的领导来找DBA提扩容需求。
这给了DBA非常大的压力，实在是僧多肉少，无力回天，DBA也因此受了不少委屈，这时候钉钉稳定性团队主动站了出来，帮DBA分担了大量的的压力，他们将数据库的扩容需求根据业务的重要性进行优先级划分，统一扩容需求，DBA根据优先级顺序，结合业务的目标容量进行判定，在有限的资源下有条不紊的进行扩容，保证资源优先用在刀刃上，大大提升了扩容效率。
2、资源紧急协调
疫情忽然爆发，所有人都预期流量会增长，但涨多少谁也不知道，必须要早作预备。为了保证资源不成为系统扩容的阻力。DBA和云资源团队进行合理规划，短期内通过借用集团上云的机器，同时缩容其他BU数据库集群，凑出400台左右的机器，保证高优先级系统的扩容需求，同时协调云资源进行搬迁，在短短几天内搬迁了300多台机器到钉钉资源池，保证了钉钉所有数据库的扩容需求。
资源到位后就是检验数据库弹性的时候了，依托于PolarDB-X三节点分布式的部署架构，我们可以较为方便的对原有集群进行在线升级和扩容，对用户影响很低，并保证数据的一致性。有些场景用户需要从原有集群将数据迁移到分库分表更多的新集群，我们利用DTS搭配成熟的管控平台也能较为流畅的完成。很终我们可以做到只要有资源，数据库也能具有极致的弹性，满足业务需求。
3、应急与优化
在系统高峰来临之前，数据库团队内部已经预备好紧急预案：
参数降级，调整数据库参数充分发挥数据库能力，提高吞吐
资源降级，调整资源限制，CPU隔离放开及数据库BP大小紧急上调
针对异常SQL，确认影响后紧急限流，或者通过SQLExecutePlanProfile进行紧急干预
全集群流量备库分流，依据压力情况很大可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层可以自己进行流量的生成，放大或缩小，甚至将事务比例更改后再次压测的能力。
从2021年开始，在DBA和达摩院数据库实验室科学家们共同的努力下，我们开发了ClouDBench实现了上述的需求，并在此次的战争中帮助DBA进行容量的评估。
先展示下效果：
蓝色是真实业务在某个时刻的性能曲线，绿色是我们采集DB端流量回放出来的性能曲线，可以看出两条曲线在时序上高度拟合，尤其是InnoDB内部的指标都非常接近，包括流量的波动。
当我们能够比较真实的回放出业务的workload，我们即可以对压力进行放大，以此来分析DB的容量，并分析出极限场景下的性能瓶颈，从而进行DB的优化及验证优化效果。
ClouDBench目前已经在共有云数据库自治服务DatabaseAutonomyService(DAS)中灰度上线，我们会在后续的文章中具体介绍下ClouDBench的实现，敬请期待。
文章地址：https://www.tianxianmao.com/article/online/13627.html
