互动直播：弹幕、连麦、礼物，逐个拆

弹幕：一条消息乘以房间人数

弹幕的本质是广播：一条消息要推给房间里的所有人。万人房间每秒 500 条弹幕，出口就是每秒 500 万次投递。两个设计要点：

• 连接层用 WebSocket 集群，按房间分片：同一房间的观众连到同一组节点，广播在节点内完成，不用跨节点扩散。
• 下发做合并：每 200 毫秒攒一批弹幕下发，客户端批量渲染。高频弹幕场景下，这一招能把消息量砍到十分之一。

弹幕的入口同时也是风险入口，刷屏、垃圾内容的过滤设计归到直播风控处理。

连麦：混流是分水岭

观众和主播连麦，两路流要么在客户端合流、要么在服务端混流。客户端合流省服务器但每个观看端都要拉两路流，带宽翻倍；服务端混流只推一路合成流，观看端无感知，但要付出混流服务器的计算成本——一路 1080p 混流约占 4 核机器的 1 核。多数中大型平台选服务端混流。连麦依赖 WebRTC，延迟要求和架构细节见低延迟直播的实现路径。

礼物：渲染比逻辑难

礼物的业务逻辑简单——扣费、记账、广播——难点全在动效渲染。全屏礼物动效在低端机型上掉帧是常态，两个缓解办法：动效资源用序列帧而不是视频（解码压力小一个量级）；客户端做合批渲染，同屏多个礼物合并成一次绘制。礼物高峰（活动整点）的瞬时消息量是平时 20 倍，广播队列的削峰设计要预留。

并发预算怎么排

互动功能的三本账分开算：弹幕看连接数，10 万在线大约要 20 组 WebSocket 节点；连麦看混流路数，每路约占 1 核，同时 50 路连麦就是 50 核的混流集群；礼物看峰值 QPS，活动整点按日常 20 倍预留队列容量。预算紧张时的裁剪顺序也有讲究：先降礼物动效（序列帧减帧数），再拉长弹幕合并窗口（200 毫秒放宽到 500 毫秒），连麦人数上限放最后动——弹幕和连麦是留存功能，能不砍就不砍。

互动数据往哪流

弹幕和礼物的数据流不要只进消息系统，要同步进数据层：哪些场次的弹幕密度高、哪些礼物在什么时段集中，这些是运营排播的内容依据。整条直播链路里互动层的上游是推流与分发，协议承接见推流分发方案。