大型直播活动保障S13的实践和思考

英雄联盟全球总决赛是英雄联盟赛事每年度最受瞩目的节点，也是B站全年赛事热度最高的时段。第13届英雄联盟全球总决赛（下文简称S13）今年继续在B站进行直播，本文主要分享S13赛事保障的实践和思考。

S13的业务主目标是观赛用户达到1.2亿，可拆解到赛前、赛中、赛后三个阶段：

• 赛前重在流量蓄水，扩大目标用户，通过赛事活动预热、资源位投放、预约/Push召回，将流量引流到S13赛事主房间（下文简称主房间）观赛。

• 赛中用户集中在主房间，重点在提升用户观赛以及互动体验，提高用户的转化率和留存率。

• 赛后引导观赛用户会到稿件播放页观看回放，在评论区参与选手打分，在动态/话题持续发表自己对赛事的观后感。

^{图1 S13整体介绍}

因此，我们的保障目标是保证系统在洪峰流量下为用户提供稳定的功能和流畅的观赛体验，配合业务侧达成业务目标。面临的挑战概括为两点：

1. 洪峰流量大：难点在如何估算业务指标、如何正确将业务指标转换为技术指标、以及如何应对高并发流量。

2. 牵扯的业务范围广：难点在如何不缺不漏、以及如何在业务迭代压力大的背景下尽可能提效的完成保障。

接下来让我们一起探讨本次保障是如何落地的，以及在大型活动保障上带来了怎样的思考。

通过上文对业务主目标的介绍和拆解，可看到业务目标的达成依托于赛事各阶段为用户提供的功能和体验，保障业务主目标达成也就是保障S13所有要落地使用的业务功能。因此，制定技术保障计划的思路是：首先确定S13要使用的业务功能范围和各功能的业务指标（如曝光量/转化率等），其次将其转化为技术链路和技术指标（如QPS/TPS），最后运用技术手段对齐进行保障。

下图为S13的保障计划和时间线，下文也将逐步介绍我们是实践和落地的：

^{图2 S13整体保障计划}

业务场景地图指的是S13所有落地要使用的业务功能，圈定了我们要保障的业务范围；核心业务指标在S13中指的是PCU（Peak Concurrent Users 直播间峰值在线人数)，作为直播场景重要的指标，决定了我们要保障的高并发量级。

项目立项后的第一时间，产运研测各方一起讨论敲定了业务场景地图，共60+的业务功能，为便于下文具体讲解如何将业务场景地图/业务指标转化为技术链路/技术指标、以及使用的技术保障手段，首先将S13核心功能介绍下：

^{表1 业务场景示意图}

• 活动页：S13投放了多个活动页提高用户的参与度，如用户可以在主活动页上追踪赛程信息，观赛的同时参与预测、观看、分享、签到等任务。

• 流量入口：S13作为一年一度的重要活动，投放在多个资源位，用户从这些入口进入主房间；赛后，用户从主房间退出再次返回这些流量入口。该场景需要关注返回时的自动刷新机制带来的尖刺流量。

• 主房间：S13最核心还是在直播间内，包含流的观看和功能互动两部分。流观看从稳定性来看，上行流和下行流需要保证稳定可靠容灾；从带宽成本来看，还需要考虑P2P覆盖率、转码技术。此外，每次进房需要获取房间底层信息、功能数据（如榜单/运营位/底部Tab/历史弹幕等），在比赛期间，还有天选时刻、热力特效、Combo弹幕等互动玩法。其次，房间内的发弹幕/送礼特效等功能均依赖长连接，而长连接的压力是PCU级别的放大效应。最后，终端的性能表现、播放的质量监控也是保证用户观赛体验重要的一环。

• 稿件播放页/动态等：S13不仅是观赛后就结束了，B站作为一个业务形态十分丰富的平台，用户还可以去观看直播回放、知名解说、在动态话题评论等参与讨论。

^{图3 S13核心业务场景}

实际执行中，我们建议利用表格形式将业务场景地图和业务指标罗列出来：

^{表2 S13业务场景地图一览表表头参考}

^{表3 S13赛事各阶段PCU预估}

将业务核心指标转化为技术指标，指的是利用曝光量/转化率/点击率等转换成技术指标QPS/TPS。S13的业务指标PCU可等价于曝光量，一个业务功能对房间在线用户同时曝光。根据我们的经验，基本可以按照目标QPS=曝光量*转化率1*......*转化率n/分摊时长=PCU*转化率1*......*转化率n/分摊时长。

^{图4 技术指标QPS/TPS的流量预估模型}

下面通过几个典型场景具体说明该模型的运用，以及主房间这类高在线房间遇到的瓶颈问题，我们是如何通过热门房间缓存、流量打散、流量隔离和下滑预加载等技术手段解决的：

功能概述：用户从闪屏、首页推荐、全量Push、小黄条等资源位进入主房间时，终端向服务端请求流地址/房间底层信息/历史弹幕等数据，使主房间成为高在线房间，带来单房间热点问题。

QPS预估：总进房QPS=各资源位进房QPS之和。以全量Push为例，Push进房QPS=全量用户数*送达率*点击率/推送时长（全量用户数*送达率=Push曝光量，推送时长=分摊时长）。

^{图5 进房场景QPS趋势图}

技术优化：单房间热点问题使得系统内获取房间维度数据成为瓶颈，优化手段是通过PCU指标高低判定是否为高在线房间，通过将高在线房间加入热门房间内存缓存来承接高并发请求。

^{图6 高在线房间进房场景优化}

^{图7 进房场景缓存命中率}

功能概述：开启天选时刻，主房间弹出天选参与框，用户若点击一键参与则参与本次天选，用户若点击关闭则放弃本次天选，到达设定时间后，从所有参与本次天选的用户中选出中奖用户。

^{图8 直播间天选时刻}

QPS预估：参与天选接口的QPS=PCU*点击参与转化率。

技术优化：当PCU是百万千万级别时，该场景存在写瓶颈。优化手段是通过流量打散，将参与框对用户的弹出时间错开，分摊在一定时间内对所有用户展示完（分摊时间不会影响用户的参与时间），并且根据PCU来自适应调整分摊时长。经调整，QPS=PCU*点击参与转化率/分摊时长，有效化解了尖刺流量超出系统承受能力的问题。

^{图9 天选时刻打散}

^{图10 参与天选接口的尖刺流量}

功能概述：主房间内多项功能依赖长连接，例如用户在主房间发送一条弹幕，长连接会将此条弹幕广播到所有与主房间建立连接的终端。

QPS预估：长连接边缘节点的压力=N*PCU（N是同时发生的广播事件）。一方面，N*PCU越大，带宽成本越高；另一方面，实际并不会将所有事件都广播出去，否则干扰用户的观看体验。

技术优化：我们将主房间这类高在线房间的监控和控制与其他房间隔离，针对主房间各广播事件的QPS和Size单独监控、单独限流，通过单独调控主房间使系统压力、带宽成本和用户体验达到一个平衡。

^{图11 总带宽和高在线房间带宽隔离监控}

功能概述：如前文介绍，主房间的散场路径分别是退回至进入房间之前的流量入口页面和下滑至另外一个直播间。

QPS预估：

1. 散场路径一为流量入口带来的QPS=PCU*退回点击率；

2. 散场路径二为下滑的下一个直播间带来的QPS=PCU*下滑转化率。

与电影散场时观众同一时间集中走出观影厅类似，上述两个散场路径的QPS是非常明显的尖刺流量。

^{图12 散场场景的尖刺流量}

技术优化：

1. 散场路径一：出于推荐效果的考量，用户停留在主房间超过一定时间后再回退至流量入口，部分流量入口会触发自动刷新机制。但并不是所有用户回退后是继续消费最新推荐内容。因此，采取的手段是在部分时间段避免触发自动刷新机制，更自动化的手段是当超出系统承受值时，自动控制终端不触发自动刷新。

2. 散场路径二：由于主房间的PCU过高，导致下滑的下一个房间也成为一个高在线房间，依赖高在线房间SDK可使该房间自动进入热门房间缓存。但根据对推荐结果的分析，我们发现推荐的下一个房间聚集在有限的几个赛事房间。为更安全的防御这类瞬时尖刺流量，优化手段是基于推荐结果，利用这几个赛事房间作为主房间下滑的房间候选池，并提前加入热门房间内存缓存。

^{图13 散场路径二优化后缓存命中率效果}

同一个下游，可能被多个业务场景同时调用，该下游的流量是所有被调用之和。因此除了关注某个指定接口的QPS，还需以业务场景维度和整场活动维度来关注，下文我们还会再探讨实际操作上如何去做。

另外，从项目成本以及资源考虑，赛事期间的流量远高于日常，所需要的资源也远高于日常，需要提前盘点各阶段成本、进行资源的采买，因此全局估算流量也是资源容量预估的前提。

确定业务场景地图后，参与人和团队的确认需要结合保障事项和组织架构两方面考虑。

参考RASIC原则，保障事项拆分为若干项子任务，每一项子任务需设立负责人以及明确责任边界、目标和DeadLine。另一方面，实际过程中不免存在交叉事项涉及多方资源协调，因此根据保障事项涉及到的部门，分别设立了部门级别的方向负责人，方向负责人被充分授权负责协调保障事宜。最后，建立定时定期同步进展和风险的机制，也是整个项目顺利运行的重点。

^{图14 保障接口人思路示意图}

除了前文所述用户强感知到的业务功能之外，还有基础建设部分，如业务功能底层使用到的流媒体、长连接、账号、风控等，我们将其归纳在业务基础建设中分专项进行保障。以及从B站的整体基础架构来看，各层基础组件如动态/静态CDN、SLB、入侵防御WAF、统一网关APIGW、内部服务发现Discovery、PaaS、存储Redis/DB、异步消费Databus、网络、大数据等的资源预备、多活容灾能力、应急预案，我们将其归纳在技术基础建设中整体保障（见图2）。

接下来我们将重点讨论技术链路的梳理、故障演练、全链路压测、预案SOP、变更管控和赛中跟踪的实践和思考：

^{图15 重点保障事项时间线}

技术链路梳理需要得到：

1. 该业务场景涉及到的请求接口以及每个接口的链路依赖

2. 这些请求接口以及链路依赖的QPS/TPS

故障演练、全链路压测以及后续的SOP、监控都依赖技术链路的梳理结果。根据代码梳理技术链路是常用的方法：

Step1：梳理该业务场景下，涉及哪些用户在什么时机下，在哪些位置上做什么动作，即用户、终端、服务端三者的交互。

Step2：根据交互流程，确定终端和服务端交互的接口。

Step3：下钻每个交互接口的链路。

但在S13中，存在两个问题：

1. 时间成本高：根据经验，完成一个场景的技术链路梳理需要0.5d~2d（与场景复杂度/熟悉程度相关），60+场景共需要100d左右。

2. 准确性：人都有百密一疏，纯靠人看代码容易存在纰漏。

因此，联同业务架构团队，我们在服务质量保障平台Advisor（下文简称Advisor）上集成了辅助工具：在Advisor上定义S13涉及到的业务场景，通过抓包走一遍该业务场景下用户的行为路径，将抓包结果录入系统，并根据Trace自动输出链路依赖，同时计算链路依赖的放大情况。

^{表3 Advisor场景管理}

^{图16 技术链路示意图，其中每一个卡片标记放大倍数}

根据前文流量预估模型计算终端接口QPS和技术链路后，也可得到链路上各层依赖的QPS。也因为平台上维护了技术链路元数据，让前文提到的从业务场景维度和活动全局维度关注流量成为一件可能实现的事情，否则以文档形式记载技术链路，很难做到这一点。

^{图17 Advisor上技术链路元数据模型}

遗留的问题是，某个业务场景可能由于版本不同、用户身份不同导致技术链路不同，这里提供两种解决方案：

方式1：构造不同版本、不同用户身份多次抓包，Advisor支持将多次抓包合并作为最终结果；在此基础上，通过代码检查梳理结果是否全面。

方式2：Advisor根据线上真实请求汇总成完整的请求链路，再由技术同学从中择选S13涉及到的链路。

^{图18 基于完整链路择选}

S13中希望通过故障演练平台Fault（下文简称Fault）达到的目的是：正确识别到技术链路上的强弱依赖，强依赖应当确保有发现机制和预案手段，弱依赖应当确保可以自动降级，且降级后不影响该业务场景的核心功能。建议故障演练放在前置工作：

1. 通过故障演练可识别S13的强依赖路径，便于更有针对性的进行压测、SOP。

2. 故障演练发现的问题涉及代码改动，压测应当基于改动后的代码。

日常演练的做法是以接口维度将其中的故障点依次注入故障（可参考）。但S13的60+业务功能，逐一验证接口，时间成本太大。因此，将演练优化为两大步骤：

Step1：优先确定面向终端的接口的强弱。如果某个接口故障并不影响该业务场景的核心功能，则定义为弱依赖。例如进房场景，通过验证全屏/竖屏观看、唤起礼物面板送礼、在弹幕区发送弹幕互动等几个核心功能，从20+个接口最终确定4个强依赖接口（见表3的强弱依赖标注）。

Step2：针对Step1筛选出来的强依赖接口，联同质量工程效率团队建设了面向业务场景的故障演练，以业务场景维度整体验证。将Advisor的技术链路导入Fault，Fault自动将标注预期是弱依赖的依赖点组合排列，自动依次注入故障和调用自动化用例验证表现。

^{图19 Step2示意图}

^{图20 Fault业务场景演练}

S13通过全链路压测平台Melloi（下文简称Melloi）来发现和验证高性能/高并发带来的问题，高在线房间存在的问题也非常具有共性：

1. 热点Key问题：用户集中在主房间，以房间Id/主播Id为 Key的缓存成为热点Key。

2. 空缓存问题：赛事期间用户量相比平时翻了几十上百倍，且存在不少一段时间内没有访问过直播的冷数据用户，需要空缓存或者使用布隆过滤器防止缓存穿透造成DB的高并发，甚至部分场景需要预热。

3. 消费积压问题：赛事活动与用户行为强相关，例如观看达到X分钟可获奖励，主房间的观看量百万千万级别，要求高性能消费和削峰。

本文重点探讨基于Advisor的技术链路信息，在压测环节可做的优化：

1. 提高压测数据准备的效率：纯读接口可根据Advisor信息从线上录制流量回放作为压测流量

2. 提高压测结果回收的效率：可根据Advisor信息，与压测流量对比，检测压测流量是否已覆盖需要覆盖的链路，以及技术链路上各层的指标是否处于健康水位，并根据具体情况提供标准化解决方案的参考（例如热Key问题，可以提供统一的热Key识别和解决方案）。

^{图21 全链路提效示意图}

针对故障演练识别到的强依赖路径，需要做好预案SOP。可以缩短MTTR为目标，从1分钟发现、5分钟定位、10分钟恢复的原则准备预案：

^{表4 预案SOP模版}

基于安全变更要求，赛事直播保障期间，我们也启用了变更管控封网，严格控制线上变更

数量，同时也需要支持必要的需求迭代变更，我们采取了以下措施：

1. 整个活动保障期间：非强变更管控，根据前期场景梳理涉及到的业务功能，对其业务需求和技术需求上线变更要求进行邮件报备。报备内容需要包括变更内容、变更的风险、如有问题是否支持回滚、预案SOP等；

2. 关键赛事直播当天：强变更管控，同样来自前期场景梳理设计的业务应用，通过“变更管控 ChangePilot”平台进行创建业务+服务等级的封网策略。同时支持紧急情况下的变更需求提供绿色通道。

^{图22 强变更管控策略创建}

稳定性可观测：基于SLO体系的持续建设，我们实现了服务可用率、服务饱和度的观测/告警覆盖。赛事过程中通过稳定性大盘我们能够非常直观的观测到全站业务的稳定性情况；当服务出现可用率的下跌（10分钟平均可用率N2），相关协同群会立即推送预警工单。同时提供相关错误详情和错误根因推荐，大幅提高问题排查定位效率；

^{图23 SLO全网业务大盘}

实时监控大盘：除了全局业务稳定性的观测，赛事过程也同样会关注PCU情况、核心场景的QPS、P90耗时、限流情况；以及核心场景涉及服务的容量水位；通过应用APPID进行元信息关联，获取直播场景下相关的缓存集群、数据库实例、消息队列等组件的信息，关联实现组件容量水位的实时观测。以上指标均配置了不同档位的阈值，能够快速发现基础资源容量风险。

^{图24 赛事保障实时监控大盘}

基础数据同步：基于业务SLO视角和大盘资源视角，我们会在赛事直播过程中进行告警的应急响应处置、核心资源水位数据定时同步。直播后对告警事件处置情况以时间线方式导出，相关监控数据也会进行持久化存储，支持后续分析复盘。

英雄联盟总决赛今年已经走到了第13个年头，B站在每年的S赛保障上也逐渐积累了越来越多宝贵的经验。此外，直播每年的大型活动还有跨晚、拜年纪等，大型活动保障的经验如何以平台化的方式沉淀下来，为后续的保障提高效率是我们需要进一步考虑的。基于本次经验，以及前文探讨的直播特性问题，对于一场活动的保障可以考虑如下流程：

^{图25 大型直播活动保障平台化}

S13已完美落幕，赛事期间，超1.2亿用户在B站观看英雄联盟相关内容，决赛直播人气峰值超4.6亿，顺利完成了业务目标。本文主要探讨了S13保障的思路、落地手段，以及大型活动保障平台未来发展的可能性。最后，感谢S13技术保障的每一位同学！

实际保障工作中，大家踩过哪些坑有哪些宝贵经验呢？欢迎在留言区告诉我们。小编将选取1则最有价值的评论，送出BILIBILIWorld主题机械键盘1个（见下图）。12月1日中午12点开奖。如果喜欢本期内容的话，欢迎点个“在看”吧！