直播间10W人发弹幕

这里考的是高并发场景下的有损服务思维，怎么用可控的成本让直播间看起来很热闹，系统也不崩溃，记住三个关键的动作，第一个削峰填谷，弹幕进来别直接往数据库写，先在接入层卡一道关，限流禁言做校验，敏感词过滤，垃圾消息直接当场拦截住，合法的弹幕全部扔进去消息队列，让下游服务按自己的节奏慢慢的去消费，先把洪峰去缓存住，这是第一道防线；
第二层分层广播，分发服务从队列里拿到数据，先找承载这个直播间的几十台网关服务器，把筛选后的弹幕，打包发给网关，再由每个网关本地广播，给自己的连接的用户，中心服务不直接面对海量的终端，压力就拆成了两层，系统才不会被一波流量直接打崩；
第三个采样降级，一秒进来5W条弹幕，用户屏幕根本渲染不过来，重复的666直接去合并，低质量的刷屏内容去做降权，普通的弹幕做随机采样，但付费的弹幕，主播点名，系统通知这类高价值的消息，必须优先保留，每个时间窗口只筛选出几十条真正值得展示的，最后别忘了客户端不能无脑渲染。要根据手机性能，对当前的帧率做限流，每秒最多展示二三十条。

AI总结：
这道题考察的是高并发场景下的有损服务设计思想：当流量峰值远超系统承载上限时，不追求 100% 消息全量送达，而是通过可控的、用户弱感知的体验降级，以最低成本保障系统整体不崩溃；同时优先保证核心业务体验，让直播间维持热闹的观感。

整套方案可以拆解为三层防护机制，从接入、分发到端侧层层消化流量洪峰：

一、第一层：接入层削峰填谷，垃圾拦截 + 异步解耦

核心解决：突发流量洪峰直接打穿后端业务、存储层的问题，将同步写入压力转化为异步缓冲。
弹幕请求不会直接落地数据库，先经过接入层网关做第一道流量治理：

1. 前置拦截过滤：先完成基础限流、用户鉴权、禁言状态校验，再做初级敏感词、垃圾刷屏消息的实时拦截，直接丢弃无效流量，从源头减少无用请求。
2. 消息队列削峰：校验通过的合法弹幕，全部写入高吞吐消息队列做流量缓存，把上游突发的洪峰 “存起来”，下游的业务处理、持久化服务按照自身的消费速率平稳消费，避免突发流量直接打垮后端。
   这一层是系统的第一道流量防线，核心作用是解耦上下游、抹平流量尖刺。

二、第二层：分层广播架构，拆解推送扇出压力

核心解决：中心服务直接向海量在线终端推送消息的扇出瓶颈。
弹幕分发不采用 “中心服务直推所有用户” 的模式，而是拆成两层推送架构：

1. 中心分发服务从消息队列消费弹幕，只负责将弹幕推送给对应直播间的长连接网关集群，不直面百万级终端用户。
2. 每台网关仅维护自身连接的用户，收到弹幕后在本地完成向所连终端的广播推送。
   通过分层架构，原本单节点的百万级扇出压力，被拆解到几十上百台网关节点分摊；中心服务只和网关集群交互，连接数和推送压力指数级下降，避免单波流量直接打垮推送系统。

三、第三层：分级采样降级，端云协同保障体验

核心解决：全量弹幕传输和渲染的性能瓶颈，同时保障高价值消息优先级，做到 “有损但不破坏体验”。
用户屏幕和人眼的信息处理能力存在物理上限，每秒上百条弹幕用户根本无法完整接收，因此可以做可控的采样降级，同时严格执行分级保障：

1. 服务端消息分级处理
   • 高优先级消息（付费弹幕、主播发言、系统通知、管理员消息）：100% 全量透传、绝不丢弃，优先保障核心业务和付费体验。
   • 普通弹幕：做随机采样，例如每秒 5 万条入站弹幕，仅筛选保留几十条具备展示价值的内容。
   • 低质内容（重复刷屏、无意义灌水）：做降权丢弃或合并去重（比如重复的 “666” 做聚合展示），进一步压缩展示量级。
2. 客户端协同降级：服务端不全量无脑下发，客户端也根据自身设备性能做渲染限流，比如限制每秒最多渲染 20~30 条弹幕，超出部分进入缓冲队列或直接丢弃，避免弹幕密度过高导致页面卡顿，保障观看流畅度。

设计总结

整套方案的核心逻辑是：用分层架构分摊系统压力，用有损降级换取整体稳定，用分级策略保障核心价值。最终效果是：用户感知不到弹幕被采样，依然觉得直播间氛围热闹；系统通过层层削峰，不会被突发洪峰打垮；同时付费、系统等高价值消息的优先级得到绝对保障。