关键决策
这一页整理弹幕系统设计过程中遇到的关键决策点，每个决策都说明了问题、对比过的方案和最终选择理由。
决策 1：WebSocket 还是轮询
问题
客户端如何实时接收新弹幕？
方案对比
- HTTP 轮询：实现简单，但延迟高、浪费资源，高频率轮询会拖垮服务器和数据库。
- WebSocket 长连接：客户端和服务端建立长连接，服务端主动推送，延迟低。
决策
WebSocket。直播场景实时性要求高，轮询只适合低频场景。WebSocket 网关保持轻量，只维护连接、基础鉴权、接收消息、推送消息和连接级限流。
决策 2：每条弹幕都广播吗
问题
热门房间每条弹幕都要推给所有观众吗？
决策
大房间不能。广播放大是弹幕系统的核心压力，必须对大房间做策略控制：普通弹幕采样展示、高频用户限速、重复内容合并、礼物和管理消息优先推送。用户需要的是热闹和实时，不是逐字逐条完整接收。
决策 3：网关是否处理业务逻辑
问题
WebSocket 网关要不要承担审核、落库、统计等逻辑？
决策
网关应轻量。网关只做连接维护、基础鉴权和连接级限流。复杂审核、落库、统计、推荐放到消息服务和异步消费者。网关变重会导致扩容和稳定性变差，横向扩展困难。
决策 4：礼物是否和弹幕同链路
问题
礼物消息能复用普通弹幕的链路吗？
决策
展示可以共用分发能力，资金链路必须独立可靠。礼物拆成资金链路（扣减、订单、主播收益，强一致）和展示链路（动效、榜单，最终一致）。弹幕系统不直接扣余额，而是调用账户/支付系统完成交易，再消费”礼物支付成功”事件。高价值礼物走高优先级通道。
决策 5：在线人数是否强准确
问题
在线人数要实时准确到个位数吗？
决策
展示可以近似，结算必须准确。在线人数由网关定期上报本机房间连接数，聚合服务计算近似值，对用户展示允许短时间误差。但涉及结算的统计（礼物订单、主播收益、榜单贡献值）必须与账务系统定期对账。
决策 6：普通弹幕的可靠性
问题
普通弹幕丢一条可以接受吗？要不要保证绝对可靠？
决策
普通弹幕可以接受至少一次投递或少量丢失，低延迟优先。如果为普通弹幕追求强可靠，会把整个系统做得又慢又复杂。礼物、付费和管理消息才需要更可靠的投递语义和幂等消费。按消息类型定义语义，而不是一刀切。
决策 7：在线连接状态存哪
问题
连接和房间的映射关系存在哪里？
决策
存在网关内存。连接状态变化很快（connection_id -> user_id/room_id/device，room_id -> connection_id 列表），不适合每次写数据库。数据库只保留关键事件和审计记录。网关重启后连接重新建立，需要配合重新订阅房间。
决策 8：队列如何拆分与降级
问题
热门直播造成消息队列积压时怎么办？
决策
按任务拆分队列 + 积压降级。realtime_dispatch、content_audit、message_persist、stats_event、gift_event 分队列；礼物和管理员消息高优先级。积压时：普通弹幕队列超阈值丢弃低优先级消息，落库队列延迟时先保证实时分发，礼物队列单独扩容，消费延迟告警触发限流或降级。