干货分享｜B站DBA负责人亲述数据库大型活动保障方法论  

     作者介绍       

陈阳-B站DBA Leader

十年以上数据库运维经验, MySQL 深度用户，在数据库自动化运维、分布式数据库上均有一定积累，累计申请并授权发表多篇数据库方向技术发明专利。

—————————————————————————————————————————————————————

B 站每年都会举办多场大型活动, 诸如: 跨年晚会、拜年祭、大型赛事直播、会员购大促等. 随着近几年一些高质量的活动受到用户关注量越来越大, 活动时的流量和并发也在一次次地刷新着历史记录, 其中 2021 年的《英雄联盟》S11全球总决赛观看人数破亿。在超高并发的背后, 对数据库性能以及稳定性的也提出了更高的挑战。

除了大家熟知的动画、漫画、游戏、学习资源等视频播放之外，B 站还有直播类、电商类、游戏类业务。不同的活动背后DB所面临的压力是不同的，B站的大型活动大体可以分为大型活动直播以及电商大促两个部分，流量的峰值一般会集中在前者。对于大型活动直播, 其主要压力场景体现在: 数据库持续高并发读写、缓存热 Key、 大量实时排序场景、预期外突发流量等; 而电商大促的核心关注点在: 秒杀期间高性能、高可用、热点库存并发更新瓶颈、缓存与 DB 一致性等。

每一场活动对于整体业务来说都是一次大考，我们通过一次次的活动去不断去总结梳理、优化，持续提升系统可靠性，然后去迎接下一次更大体量的挑战。其中包括系统容量评估、业务场景存储选型优化、数据库架构优化、SOP 流程化、应急预案场景丰富等等, 不断丰富的经验积累使得我们在顶级流量面前也能平稳支撑。

今天就来具体说说B站是如何进行数据库保障应对重大活动的，活动数据库保障工作主要分为活动前全链路压测、活动中保障、活动后复盘三个阶段进行。

活动前全链路压测

活动前的全链路压测是大型活动保障至关重要的一个环节，它是整体活动能否按照我们的期望平稳运行的基础。正常情况下我们在举办大型活动之前至少3个月就会开始进行一系列的容量评估以及全链路压测工作，一般会进行至少 3轮的压测，期间也会穿插一些预案场景的演练，比如异常宕机、流量过载、缓存击穿等不同的场景, 配合混沌工程演练, 包括网络抖动、数据库性能抖动、突发慢查询等各种异常场景, 去提前发现并修复系统存在的薄弱环节，使系统的吞吐水平以及可靠性有不断提升, 直至满足我们的压测期望值。

1.压测前的评估工作

水位线指标评估与巡检

在压测前一般会对数据库的水位线进行评估，B 站的数据库会根据其关联的微服务, 自动生成L0 – L3 不同的等级, 对于不同的等级数据库设定不同的水位线, 比如和核心的 L0 级别的数据库我们会保障水位线在 50% 以下。 数据库的水位线评估指标一般包含物理资源、CPU使用率、内存使用率、IOPS、QPS、TPS等等。 而巡检内容包括峰值物理资源使用率, 以及SQL P9999 分位响应时间、长事务、慢查询 、buffer pool 命中率等等。

2.压测前的准备工作——数据准备

压测数据制造

关于压测数据有两种选择，使用克隆集群或者原集群建影子库/表。

克隆集群常见的方式就是基于备份新建一套同等配置的集群进行压测，这种方式会因为克隆集群与原集群的性能不能百分百的对标而导致一些意外。了解SSD的同学都知道其磁盘的性能和它的存储容量以及读写次数都有关系，当克隆的集群分布在较新的机器上时，性能可能比原集群要好，这就导致了压测与实际情况不对等的结果。而且当活动涉及的库特别多时，这种方式对资源的消耗也是一个较大的挑战。所以B站选定的是基于原集群进行压测，可这种方式有个逃不开的问题，怎么保证不影响到我们线上的业务数据呢？这就涉及到数据隔离与存储了。

数据隔离与存储

原集群的方案又分为影子库和影子表, 两者也有各自需要面临的一些挑战。

影子库会造成数据库的连接数翻倍，线上业务请求连接线上数据库，压测请求连接影子库，这种方案的优点是实现简单, 只需要从连接串区分即可。

影子表方案需要做的改造比较多, 通常会根据表名克隆出一个固定前缀类似bilibili_shadow_来复制表，同时需要在框架SDK/Proxy去做一些改造，通过流量标识来识别压测流量，并通过SQL改写的方式使压测流量进入影子表里。

数据清理

这个工作一般由后台任务控制，选择在业务低峰期的时候进行分批清理，防止影响到线上的任务。

3.压测中的重点工作——发现系统瓶颈

压测中想要找出使哪个环节出了问题，就需要引入全链路压测跟踪工具了，下图是B站自研的一个分布式全链路跟踪工具，通过它可以清晰的看到哪个环节的耗时较久，帮助我们快速定位问题环节，有效提升问题的处理优化速度。

这里值得一提的是我们推荐应急预演放在压测的流程中进行，而不是在业务低峰期进行，因为系统在高负载下如果发生异常，我们面临和需要处理的问题要比低负载复杂的多，所以我们在这种情况下模拟出来的场景才是最真实有效的。关于应急预案的具体内容，大家感兴趣的话，单开一篇文章来详细说说B站数据库的那些应急预案。

4.压测后的收尾工作——压测报告

一个合理的压测报告需要包含重点关心的核心指标并能指导你完成系统优化。对于DB来说，我们会重点关注P9999分位的响应时间、QPS、TPS以及磁盘的IOPS、利用率以及CPU、内存以及慢查询等指标是不是在我们的可控范围之内, 以及我们的HPA、VPA策略是否在达到负载阈值之后能正常进行自动扩容。

我们的 TiDB 计算节点是放在 k8s 里的, 这样当计算节点出现瓶颈的时候可以实现自动扩容, 而 MySQL 的快速扩容则依赖于 Proxy 的只读节点流量在线调度。

值得一提的是除了要考虑活动期间依赖业务的压测之外，还需要考虑活动过后带来的连锁反应, 可能会导致对其他关联系统产生大量的压力，针对这些地方也要做好充足的准备。我们也经历过保障了活动的平稳运行, 但是没考虑到活动结束后大量用户涌入点赞、评论等行为而导致的其他系统过载的场景。

活动中保障工作

1.活动监测

很多同学认为保障的核心工作都在前期，所以只要前期的准备工作做的充足，那么整个流程基本上就算大功告成了, 但是我想说其实并不是这样。活动期间的保障工作如果做的不到位, 可能会导致前面所有的努力都归零。所以活动中的保障以及应急预案执行也是非常重要的一个环节, 因为从这里开始, 你将不再有任何试错的机会。

活动期间应该每隔一定的固定时间, 根据监控大盘巡检并关注系统的核心指标以及利用率, 然后做出阶段性总结。一般我们会重点关注核心请求响应时间、 QPS/TPS趋势、水位线等数据，这些数据可以帮助我们来判断系统状态并且提前为下一步的动作提供决策依据。举个例子，当资源水位线到达60%的时候，我们就应该根据流量趋势去考虑是否需要提前扩容; 当在线人数接近我们 80% 最大容量的时候, 我们就需要开始准备启动限流策略。

2.故障快速止损

即使在前期做了很多轮的压测以及预演，但是明天和意外哪个先来谁都说不准。在面对意外情况，如何快速解决问题成了关键点。数据库作为一个非常重要的基础服务, 日常线上运维中我们会按照 1-5-10 (即1 分钟发现问题, 5 分钟定位问题, 10 分钟解决问题)的标准来要求自己. 在大型活动期间我们的期望时间会更短。

对于预案内的异常场景, 按照标准 SOP 执行预案即可, 比如常见的宕机、慢查询、并发过高、主从延迟等, 我们有标准的扩容、限流、降级等预案应对, 只要进行了事前有效演练, 一般都能在很短的时间内恢复业务。

对于不在预案之内的异常场景, 是相对比较容易出问题的点, 新手经常会一头扎进问题底层查找Root Cause.  而一个有经验的 DBA则是是保留现场后立刻尝试止损。这里建议参考Google SRE方法论。简单的来说, 在处理大型线上故障时，一般会至少3个DBA参与到事故处理中:

第一处理人：一线处理人员, 专心处理问题；

发言人：周期性地同步故障进展、状态, 沟通内外业务影响；

事故总控人：根据事故影响以及处理进展, 进行任务分配以及协调资源, 以及帮助第一处理人最优决策。

3.故障诊断与处理

关于问题定位的方法论，根据谷歌SRE的相关理论结合自身实践总结：故障排查过程就是反复采用假设 ->排除的过程，这边就不展开讲了，推荐小伙伴们阅读《SRE: Google 运维解密》11-15章的内容。

活动后复盘工作

最后一个流程就是复盘会了, 复盘的意义是让我们从全局的角度上来回顾整个活动, 其中包括不止数据库, 还有其他涉及到的各个系统. 一来可以互相了解彼此的保障流程以及遇到的挑战和解决思路, 更好地进行下一次的配合, 二来是总结一下自身还有哪些环节可以持续优化, 为提供越来越好的用户体验而努力。 另外会将每一次活动的监控数据长期保存，为以后的活动规划提供一些参考依据。

写在最后

失败乃成功之母是伪科学，只有失败之后认真复盘总结，失败才能成为成功之母。 数据库保障工作也是一样的，不要害怕出现问题，出现问题及时优化处理，时常总结复盘，积累的实践经验会成为你最厉害的武器。

—————————————————————————————————————————————————————

扫码添加小树回复关键词「0224」即可获得讲师PPT哟～