疫情期间数据库压力激增的处理经验---钉钉

挑战：

1、 系统所需要的容量是多少，无法预估

第一次容量评估，大家给2月3号定了个目标是日常峰值的3倍，随着2月10号开课高峰的到来，又将2月10号的目标调整为10倍，之后又因为2月17号开学季的到来，再次将目标调整为40倍。所以总容量相比日常峰值，翻了40倍！

2 、时间紧，扩容需求众多，资源不足

疫情流量的猛增，给系统带来的冲击不亚于每年的双11。电商会花半年时间准备双11，但这次留给我们的时间只能以小时来计。另一方面，出于成本的考虑，资源池中基本没有空余的机器，现有的资源部署密度也比较高，如何腾挪资源在较短的时间内为接近20个核心集群进行扩容是一个很大的问题。

3、 极限场景下如何保障系统稳定性与用户体验

在各种因素制约导致集群无法扩容且系统已经达到瓶颈时我们能怎么办？有哪些应急手段能用? 是否存在一个平衡点，将对用户的影响降到最低？

 

应对措施

1 、人员合理化安排

1）数据库团队成立疫情期间业务保障小组

小组成员包含了数据库团队DBA/数据库内核/CORONA/TDDL/DTS/精卫/NOSQL各产品线同学。

根据业务线进行分工，每个DBA跟进一个业务线，参与高峰期的保障，及时播报线上系统状况与水位，让重保决策人员及时了解系统的状况。对线上出现的问题紧急处理，保证问题在短时间内得到修复。对不合理的业务场景进行优化，保证已知问题只出现一次。参与系统的压测，发现潜在风险点及时修正，对系统容量不够的系统进行及时扩容，在资源满足的情况下让数据库在高峰来临之前已经具备足够的容量。

2）数据库团队与稳定性团队紧密合作

稳定性团队主动站出来，帮DBA分担了大量的的压力，他们将数据库的扩容需求根据业务的重要性进行优先级划分，统一扩容需求，DBA根据优先级顺序，结合业务的目标容量进行判断，在有限的资源下有条不紊的进行扩容，保证资源优先用在刀刃上，大大提升了扩容效率。

2、 资源紧急协调

为了保证资源不成为系统扩容的阻力，DBA和云资源团队进行合理规划，短期内通过借用集团上云的机器，同时缩容其他BU数据库集群，凑出400台左右的机器，保证高优先级系统的扩容需求，同时协调云资源进行搬迁，在短短几天内搬迁了300多台机器到资源池，保证了所有数据库的扩容需求。

3 、应急与优化在系统高峰来临之前，数据库团队内部已经准备好紧急预案：

• 参数降级，调整数据库参数充分发挥数据库能力，提高吞吐
• 资源降级，调整资源限制，CPU隔离放开及数据库BP大小紧急上调
• 针对异常SQL，确认影响后紧急限流，或者 通过SQL Execute Plan Profile 进行紧急干预
• 全集群流量备库分流，依据压力情况最大可 100% 读流量切换到备库
• 准备数据库弱一致脚本，在必要时进一步提高数据库吞吐

4 、DB容量预估及性能分析

通过经验并和业务方一起进行全链路压测进行DB容量（集群能支撑多少读写）的预估，这种方式有以下几个问题：

• 压测数据集和数据库总量相比往往比较小，DB命中率基本100%，这对于分析有IO的业务模型存在较大误差
• 成本较大，需要打通上下游整个链路，较多的同学参与
• 即使全链路压测，真正压到DB端的往往也只是核心的几个接口，无法100%覆盖线上所有的接口，而很多慢SQL往往都来自这些易忽略的接口

解决这个痛点问题的方法大家其实很容易想到–只要把线上的业务流量全部采集下来回放一遍即可，但实现起来是非常复杂的。我们真正需要的其实是针对DB的一种通用的单链路压测能力，并不依赖上游业务，DB层可以自己进行流量的生成，放大或缩小，甚至将事务比例更改后再次压测的能力。

 

成果及思考

1、人员组织：

首先在人员组织上，业务和开发要对突发流量具备敏锐的嗅觉，及时发现提早准备，由业务方稳定性负责人成立应急小组，梳理依赖业务以及对应后台系统，将各业务线owner和后台数据库产品owner纳入应急小组。由应急小组统一容量规划、人力配备以及资源协调，实现业务方/后台产品团队/资源团队联动。

2、技术架构：

在技术架构上，一方面是要使用具有足够弹性的数据库产品，保证使用的数据库产品有自由扩容和缩容的能力，既要保证流量来了之后能扩上去，也要保证日常流量时可以缩下来。管控等各个运维组件需要在实现自动化运维的同时，对于很多关键操作留有应急开关，确保在一些极端场景下，可以较方便的从自动驾驶切换成手动模式，确保任务平稳高效的运行下去。

3、应急手段：

在面对系统瓶劲时，在业务上和数据库产品上都要提前做好预案，在业务上要有降级和限流功能，在系统无法承受压力时，可以降级一部分非核心功能，限制一些次核心功能来保核心业务的正常运行。在数据库产品上需要具有在不扩容的情况下，通过一些优化手段瞬间提升数据库吞吐的能力，更重要的是这些能力需要有较好的兼容性，在不同的部署环境，不同的DB架构下都具有相应的工具和预案。

另一方面，我们需要有评估和检测预案效果的手段，将能力透传给业务的owner，在大促之前，自动进行大量的DB单链路压测，评估系统水位，发现性能瓶颈，优化DB参数，验证预案效果。