php随机打散技巧_轻松扛下超3亿实时人气B站S12技能保障内幕揭秘

卫旋，B端技能中央资深开拓工程师，S12技能保障项目总卖力人。

一、序言

英雄同盟环球总决赛是一年一度最为盛大的电子竞技比赛，在海内关注度极高。
11月6日，DRX战队以近乎奇迹的办法，一起从入围赛披荆斩棘拿下了S12环球总决赛的冠军。
相称励志，恭喜DRX！

B站作为今年S12的官方直播渠道，哔哩哔哩赛事直播间实时人气一度超过3.1亿。
如何保障全体S赛洪峰流量下系统的稳定性和流畅性，给我们带来了巨大寻衅。

为此，我们在7月尾成立了S12技能保障专项，展开了为期3个多月紧锣密鼓的技能预备，我们的目标是可以实现“喝茶保障”。

二、如何实现

经由盘点，我们把S12技能保障依赖的各项事情拆分为赛前、赛中、赛后三个阶段，如下图：

1、项目启动

S12技能保障须要公司多个技能团队之间的紧密合营，涉及业务研发、SRE、根本架构、DBA、大数据等近300人。
从上游业务充分搜集S12干系资讯后，我们调集所有干系团队卖力人召开了项目启动会，终极在S12技能保障目标上达成同等，争取做到全局步调同等。

2、资源预估

1）贴合业务

为了发挥资源的最大利用代价、提高资源利用率，我们与上游业务对齐了业务目标PCU（最高在线用户数）、后续宣发策略和方案，方便技能侧及时参与准备、做出合理的资源估算。

2）合理估算

从B站SRE容量平台查询到去年S11做事器峰值用量a、去年8月日常峰值用量b，粗略算出同期增长系数delta=(a-b)/b+1。

3、资源池管理

去年以前，直播资源池都是直播专属、与其他部门独立的，当直播资源池资源用尽后，须要从其他资源池折衷机器->网络测试->机器初始化->重新打label入直播池，全程人工、非常低效，常常导致线上业务发布或扩容壅塞、影相应急相应效率。

从全站视角看，大型赛事直播结束后大量用户会从直播间转向社区其他做事（稿件、评论、专栏、动态等），类似“潮汐流量”，这部分做事器冗余可以通过合池来“降本”。
合池的条件是机器运行时的标准化：

1）做事去CPUSET

由于直播的实时性和对延迟的敏感性特色，我们的业务场景无法接管高概率的CPU Throttle带来的超时。
大量做事利用了CPUSET的绑核策略，CPUSET无法资源共享、无法合池、造成一定的资源摧残浪费蹂躏。

内核同事帮忙排查后创造，PHP做事的高概率CPU Throttle是由于同时并发实行的R进程过多，导致CPU Quota被击穿。
排查PHP根本库创造，直播PHP做事利用了Swoole多进程模型，根本库会在每个Worker进程内设置一个定时器用来更新配置，1s检讨一次，多个进程大概率会在同一时候被唤醒。
修复方案有两个：1）打乱进程定时器实行的随机性，减少“碰撞”；2）基于inotify进行配置更新，废弃根本库定时器。
由于业务代码里也大量利用了定时器用来对直播热点数据做内存预加载，以是终极是采取了方案1，更新根本库后效果非常明显。

protected function funcWorkerStart(){ return function (\swoole_server $Server, $iWorkerID) { // 部分做事会在init_callback中注册worker timer做配置加载 // 但是会带来并发R过多导致cpu throttle，此处做下随机sleep 10-500ms mt_srand((microtime(true) + posix_getpid()) 10000); usleep(mt_rand(10000, 500000)); Main::init(); //配置文件定期加载 $config_reload_cb = function () use ($C, $Server, $iWorkerID) { app(Metrics::class)->flush(); // load config... // config check... // reload worker... }; //注册定时器 swoole_timer_tick(1000, $config_reload_cb); }; }

对付Golang做事，我们引入了automaxprocs来自适应调度在Linux CFS调度模式下的GOMAXPROCS，并对所有Go做事做了代码lint检测。

2）宿主机内核升级

直播部分老机器内核版本过低无法参与合池，并且存在cgroup泄露问题[1]，造成业务超时抖动。
为了合池后不影响其他部门在线业务运用，须要对老内核机器进行内核升级。

B站操作系统团队统一了内核版本，根治了困扰业务已久的cgroup泄露问题，同时基于Group Identity对在离线业务混部做了CPU隔离优化。

完成直播PAAS合池后，缓解了部门之间机器多份冗带来的资源摧残浪费蹂躏。
在线业务利用B站SRE容量管理平台按需分配，大大提高了资源利用率。

4、业务场景拆解

1）确定保障范围

B站直播经由8年的发展，已经具备了多样化的直播间玩法、能力，可以支持不同类型直播场景。
今年的S12我们也推出了很多新玩法，涉及的各项能力要在对应的后台配置好后才会呈现给用户，不同的功能玩法由不同的技能团队支持，以是首先要确认S12用到的已有能力和新增玩法（共30+个），圈定保障范围。

2）确定场景分级

分级标准如下：

① P0

部门核心用户场景所对应业务：需知足月日均DAU >= xx W；如不知足条件，降级到L1

② P1

部门L0业务主场景利用中依赖的紧张业务核心的二类业务不知足L0的部门核心用户场景所对应业务不知足L0的部门紧张营收业务强依赖下贱业务

③ P2

部门给用户供应的其他业务强依赖下贱业务

如上所示，我们从DAU、营收数据、依赖等维度定义了做事的分级标准，按照场景拆分确定保障等级。
终极根据S12涉及到的30+个功能拆解出10个P0场景、16个P1场景、9个P2场景。

对付P0和P1的场景要重点覆盖混沌工程测试、客户端性能测试、做事端性能压测、生产多活演习训练、可不雅观测监控等，担保做事架构高可用。

3）梳理场景舆图

① 定义

场景拆解后，针对单一场景将关联的业务逻辑（微做事调用关系、接口依赖等）进行全局梳理形成场景舆图，帮助场景卖力人和决策者快速理解做事本身的依赖情形。

② 梳理规范

场景名称：xxx

有了场景舆图，对S12的技能管理和优化会更有针对性。
整理场景舆图的过程，一方面加深了研发、测试对付场景逻辑的认识，一些历史问题也会变得清晰；另一方面这些元数据有助于后面各项技能架构优化、监控元数据的校准。

5、高可用架构

分布式架构下微做事之间相互调用十分繁芜，一个点位故障极有可能影响整条链路的稳定性，为此我们做了长足的架构演进准备。

1）单点管理

分布式架构下，单点本身不具备容灾能力，最随意马虎涌现问题。
该当优先处理掉，紧张有：

运用单点：哀求所有运用都该当多实例支配（>2）。

2）高在线自适应保护

千万直播场景下，一场直播结束会有大量用户退出直播间回到流量入口页，对其他网关及下贱带来数倍的压力放大。
由于Prometheus监控有采集窗口，实际的要求“毛刺”比下图所示还高。
从流量转化数据上看，实在80%的要求是不必要的，用户可能已经关闭APP了。

针对这类Case设计了高在线自适应降级保护方案。
通过做事端与客户端协议打通，直接从源头上避免不必要的用户热点行为、对后端做事器的流量冲击。

目前已经上线的保护策略如下，识别到当前直播间热点后：

退出直播间不自动刷新流量页针对不主要的KV配置等要求，做随机延迟打散针对广播集中触发接口热点要求，做随机延迟打散动态调大离线数据上报间隔，降落做事器压力API Gateway限流后自动触发客户端流控

3）混沌工程

在生产环境中运行分布式系统，难免会有各种不可预见的突发事宜、故障发生，而微做事之间相互依赖，可能会产生非常连锁反应。
我们该当致力于在这些非常行为被触发前，尽可能多地识别风险，然后针对性地加固戒备，从而避免故障发生时所带来的严重后果。

混沌工程正是这样一套通过在分布式系统上进行实验，主动找出系统中薄弱环节的方法学。
这种通过实证的验证方法可以为我们打造更具鲁棒性的系统，同时让我们更透彻的节制系统运行时的各种行为规律，也能在这个过程中及时针对性的补齐系统预案。

B站从去年开始引入混沌工程，基于chaosblade二次开拓，领悟监控、问题管理形成初步知足业务微做事管理的故障注入平台。
但逐渐创造chaosblade只能掌握端口级别的故障，爆炸半径过大，影响较大无法在生产环境实行。
今年自研了掌握粒度更细、爆炸半径更小的混沌演习训练平台，可以掌握到接口、用户粒度的故障。
详见下图：

针对S12核心L0/L1场景，我们在进房、送礼、发弹幕、首页等场景进行了故障演习训练、红蓝对抗，主动创造并管理核心链路上的几类非预期问题：

代码问题，弱依赖被缺点地实现为强依赖，导致核心链路不通；

4）同城双活

机房故障每每是灾害性的，会大大降落用户体验乃至涌现客诉，对用户和公司来说都是巨大丢失。
多机房failover能力显得至关主要，我们对直播核心业务场景实现了同城双活（首页、进房、送礼、预开播等），担保在机房失落联、断电、失落火等极限情形下，可以快速决策并切流，最大限度担保用户体验不受损。

吸取去年“B站713故障履历和教训”，SRE平台和根本架构团队研发了 Invoker多活切流平台。
经由多次生产切流演习训练验证，单次切流均匀时效5分钟内。
大大提高了切流效率，避免故障影响面持续扩大。

5）网关迁移

直播第一代API Gateway是基于Envoy二次开拓，支配在IDC物理机。
资源预估涌现偏差时临场扩容非常耗时，须要做事树挂载->审批->机器初始化->运行时初始化->灰度->接量→测试→SLB灰度→SLB全量，均匀耗时30分钟+。

去年S11总决赛现场踩过这个坑，当时靠手速扩了20分钟才扩上8台，扩完之后一波突发流量差点儿炸了，CPU峰值90%了，好险！

同时Envoy网关C++编写、代码构造十分繁芜、调试困难、很难掩护，无法一键支配。
今年我们将核心做事的BFF（Backend For Frontend）全部迁移到新的自研Golang API Gateway。
紧张有以下上风：

支持容器化支配支持自动弹性伸缩HPA，分钟级别即可完成扩容！
具备快速便捷的掌握面能力：限流、降级HA：支持逻辑/物流集群隔离支持全链路灰度

目前该项目已经开源，感兴趣可以学习：https://github.com/go-kratos/gateway

6、性能压测

经由前面的优化，我们初步保障了全体技能底座的抗故障能力，接下来会通过几轮周期性压测来验证核心业务场景的极限QPS能否达到哀求，未达标的要剖析出瓶颈并做技能优化/扩容。

1）压测目标

每年大型赛事活动结束后，我们都会比拟赛期间的关键数据做存档，方便对明年目标值做出合理预估。
依据去年业务数据（在线人数、营收数据）增长比例和核心接口峰值QPS，结合接口实际调用机遇，很随意马虎估算出今年接口预期QPS。

假设去年同时最高在线N，A接口峰值QPS=a（A接口进直播间必调一次、和在线人数线性干系），前面我们和上游业务方对齐业务数据目标（同时最高在线=M），则今年A接口预期要扛QPS = a （1 +（M-N）/ N）

2）压测方案

通过抓包、代码翻阅整理出今年S12核心场景最新的接口依赖和调用时序关系（是串行还是并行），B站自研的压测平台Melloi支持对同一个场景的干系依赖接口进行编排。

今年的S12新增了很多用户玩法功能给用户带来沉浸式的不雅观赛互动体验，涉及很多写接口的压测，可能会对生产环境造成数据污染，产生舆情和客诉。

B站在去年自研了全链路压测的方案，通过全链路压测标识Context通报，在数据写入层的SDK做拦截策略，将压测写流量转发到“Mirror数据隔离层”，实现压测数据隔离。
压测结束后，压测平台联动数据库、缓存、行列步队等数据平台，快速回收数据。

S12送礼、心跳等直播核心写场景就采取了这个方案，通过对场景干系链路的高下游改造，借助于全链路压测平台真实摸底了数据库和异步JOB/Consumer的负载上限情形，设置了合理的限流，有效地保障了大型活动中写做事的稳定性。

3）压测实行

为了压测数据的真实性，我们选择低峰期在生产环境进行集中发压。
虽然是在低峰期压测，但还是有一些正常用户流量，以是一定要把稳避免压去世全体系统：

开始要逐步施压且压测韶光短一些(比如1分钟)，以防止涌现问题。

4）压测报告

压测后我们会系统整理压测报告：压测结果、目标Review、问题跟进等。

① 常见问题

② 扩容最佳实践

压测结束后，根据如下公式合理估算要扩容的副本数。

7、保障预案

保障预案紧张分为两个方面：业务层和技能层。

1）业务预案

通过场景舆图梳理、混沌工程、性能压测创造并管理了很多技能风险点，回看这些问题关键链路的技能优化，大多数链路降级调度依赖各种配置：做事配置、KV配置、高下游的配置。
为了保障在全体S12进程中及时相应、关键链路不出问题，我们整理了各个场景中可能须要临场实行的各项预案。

我们针对15个S12核心场景做了保障预案，部分预案须要多个场景卖力人进行联动、协同，会在线下线上做预案演习训练并验证有效。

2）技能预案

① 网关限流：结合前期压测的QPS，配置一个合理的限流QPS

② 做事Quota限流：支持按Zone、Caller进行限流

③ 网关降级：支持按PATH和Query/Header进行直接降级，不会将压力通报到业务做事BFF

④ 资源弹性

HPA：全称是Horizontal Pod Autoscaler，水平自动伸缩。
当业务POD CPU/内存利用率超过设定阈值后，自动触发扩容，无需人工干预。

8、质量把控

S12八强赛后，我们启动了S12强管控升级。
强管控期间，线上变更须要谨慎并报备到S12技能保障项目组进行Review把关。
详细分为两个阶段：

9、现场保障

1）可不雅观测性

往年的大型赛事保障活动，投屏的监控大盘无法直不雅观创造系统问题，业务监控遍布在各个角落，排查问题非常不便。
今年我们首先基于场景舆图梳理出了S12 L0/L1场景的核心依赖：

接口运用数据库缓存行列步队

然后环绕业务核心指标PCU（最高在线用户数）、核心场景SLO、核心运用饱和度三个维度制作了新的康健监测监控大盘，1分钟自动更新一次。

① 业务核心指标PCU

直播大部分系统和PCU线性干系，一旦有颠簸要立即关注下贱负载情形。

② 核心场景SLO

作为结果指标，对付微做事故障有着决定性的辅导浸染，涌现颠簸一定是有问题了。
对B站SLO体系培植感兴趣可以阅读：假如还没搞明白SLO，你算哪门子SRE呢？

③ S12核心运用饱和度

作为预警指标，可分为三个档位：

红：非常，须要立即参与处理橙：偏高，须要关注绿：康健，无需关注

2）告警协同

保障现场涌现最多的问题便是告警了，我们目前的告警存在告警等级不明确、告警接管人不准确、处理状态不透明、告警风暴的问题，长期会基于SLO做告警管理。
短期我们自研开拓了一套告警应急协同平台，方便研发、SRE协同处理告警，一览无余。

支持场景管理支持告警订阅：按告警ID支持告警过滤：按告警ID、按告警权重支持告警聚合：相同告警10分钟窗口内自动聚合支持告警处理协同：告警处理流转状态一览无余，方便协同

3）现场值班

① 现场指挥官

问题优先级判断应急相应技能判断和决策

② 值班职员

业务：运营、审核技能：研发根本架构：SRE、DBA、网工

三、总结展望

今年是我加入B站的第5年，回忆前几年S赛技能保障现场大家惊悸失措地处理告警（扩容、限流、降级），现场非常混乱。
即便是直播结束，告警和问题反馈也一贯不断。
今年我们通过一系列的技能升级（内核升级、去CPUSET、合池、网关容器化迁移、同城双活、HPA）和做事管理（混沌工程、全链路压测、告警协同管理），保障了全体S12直播过程中技能系统稳定、流畅，没有涌现任何必要主动限流、降级、熔断等对用户有损的技能干预手段，给用户带来了极致的不雅观赛和互动体验，实现了技能人梦寐以求的“喝茶保障”。
后续我们会对技能保障过程中的各个环节进行复盘，持续打磨技能中间件和平台、培植多活单元化、全链路压测覆盖、优化资源池调度、全面推进B站根本举动步伐云原生落地。

>>>>

参考资料

https://www.infoq.cn/article/l3qnkhnyusv9w7tgxqvp

作者丨卫旋

来源丨"大众年夜众号：哔哩哔哩技能（ID：bilibili-TC）

dbaplus社群欢迎广大技能职员投稿，投稿邮箱：editor@dbaplus.cn

关于我们

dbaplus社群是环绕Database、BigData、AIOps的企业级专业社群。
资深大咖、技能干货，每天佳构原创文章推送，每周线上技能分享，每月线下技能沙龙，每季度Gdevops&DAMS行业大会。

关注公众号【dbaplus社群】，获取更多原创技能文章和精选工具下载