走马灯与公告
Category
system / 玩法系统（信息广播件）。节点定位：走马灯（滚动条广播）与公告把「服务器里发生了值得看见的事」变成「可过滤、可限流、可送达」的消息管道——内容源、过滤风控、投递通道、播放队列四件事。广播通道的网络层在 networking 树的广播与推送，本页管的是广播什么、给谁看、怎么限。
Definition
走马灯是客户端 UI 上的滚动消息条，内容三类：系统事件（稀有掉落、首杀、大型活动开启）、运营公告（维护、版本、补偿说明）、玩家喇叭（付费点名的全服发言）。公告是同一管道的静态子集：不带滚动播放语义、需要上线可拉。共同结构：消息对象 + 过滤规则 + 投递通道 + 播放队列，四层各自可替换。
Problem
广播的坑按出现顺序：
- 刷屏与滥用：玩家喇叭被拿来做广告、骂战、钓鱼链接——广播是全服可见的公共面，没有过滤与限频就是放大器。
- 广播风暴：合服、开服冲刺、大 R 连抽触发同事件连续广播，客户端队列被打满，正常消息被淹没。
- 离线错过：事件类广播只投在线玩家，运营公告离线玩家看不到——上线拉取与事件推送混为一谈。
- 审核与即时性冲突：玩家内容先审后发有延迟、直发有风险，两难没有分层口径。
- 重复消息疲劳：同一事件（「某玩家抽到 SSR」）短时间连发 N 条，玩家直接无视，广播失去价值。
Algorithm
消息对象：统一结构，分型处理
text
broadcast_msg:
id: b-88123
type: loot_rare / notice / player_shout
priority: 10 # 数字越大越优先
channel: global / zone:3 / channel:world
ttl: 3600 # 秒，过期不再投
i18n_key: marquee.rare_loot # 文案键，多语言在客户端解析
payload: {player: u1001, item: sword-ssr}
audit: passed # 玩家内容需审核位- 内容是键值 + 参数而非拼接字符串：多语言与文案热更都在客户端侧完成，服务端只发结构
ttl控制消息生命周期：滚动条消息过了时效就不再投给新上线的玩家- 三类内容同一结构、不同处理路径，管道只有一条
过滤与限流：先审后发 + 令牌桶
| 内容类型 | 审核 | 限流 |
|---|---|---|
| 系统事件 | 免审（模板生成） | 同事件合并窗口 |
| 运营公告 | 运营后台发布，免实时审 | 发布频次后台控制 |
| 玩家喇叭 | 敏感词过滤 + 可选人工队列（先审后发） | 付费门槛 + 单人频率上限 |
- 玩家内容先审后发是底线口径：敏感词机审先行，命中人工队列则异步发（发时提示「审核中」），没有「先发后撤」的选项——撤回的成本远高于延迟
- 同事件合并：
(type, key)相同的消息在合并窗口内只发一条（或只发最高价值的一条），连抽十次只报最好的那次 - 令牌桶按类型分桶：系统事件桶远大于玩家喇叭桶，风暴时先牺牲的是喇叭
投递：在线推送，离线拉取
- 在线推送：网关按
channel广播（全服/分区/频道），走 networking 树的广播与推送的通道；事件类消息不补发，错过即错过 - 离线拉取：公告类消息服务端留存（带
ttl），玩家上线时拉当前有效列表——「错过即错过」与「上线可见」的分界就在这一条 - 合服、开服等已知流量峰值，投递侧按
channel分批 rollout，不做单点全服瞬发 - 客户端拿到消息先入本地队列，播放器按优先级出队：高优先级可抢占（活动开启），同级 FIFO——服务端不管播放节奏，只保证有序到达
与玩法侧接线
广播的事件源来自各系统，但广播层不反向依赖它们：
- 掉落、抽卡、击杀等事件由各系统发出，广播层按配置筛选「值得广播的事件」（价值阈值可运营配置）——阈值是运营杠杆，不是代码常量
- 玩家喇叭是付费道具消耗，走结算凭证；消耗在先、广播在后且广播失败不退款？不行——口径是「广播成功才扣费」，发送确认与扣费在同一事务边界内
- 广播层不写任务/成就进度，但「发一条喇叭」本身可以作为事件被任务与成就订阅（如「除夕夜发喇叭」活动）
Used By
- TrinityCore（开源 MMORPG 服务端套件，公开仓库与 wiki）：全服公告、系统通知走服务端广播接口，模板化文案与参数填充——服务端广播的通用形态参照；具体接口以项目公开文档为准。
- Colyseus（开源实时框架）：房间级
broadcastAPI 是「按房间/频道广播」的最小实现——本页投递层与 networking/07 承接的直接参照。 - 梦幻西游 / 大话西游（商业端游网易）：全服喇叭（付费）与帮派/世界频道的分层广播，是「付费喇叭 + 分层频道」的长期公开实践参照。
- 原神（商业手游）：抽卡出金不做全服广播——广播的社交价值阈值为零的品类选择，作为「不是什么事件都值得广播」的反例参照。
- 王者荣耀 / 英雄联盟（商业 MOBA）：局内击杀播报与大杀特杀播报，是「事件播报按价值分层」的参照。
可参考分析：TrinityCore 广播接口=可参考（模板化公告落消息对象一节）；Colyseus broadcast=可参考（频道广播落投递层，承接 networking/07）；网易全服喇叭=可借鉴（付费喇叭与分层频道落过滤与限流一节）；原神不广播=可借鉴（价值阈值筛选落与玩法侧接线）；MOBA 播报分层=可借鉴（事件价值分级，阈值可配置）。
Related
关系链：消息对象 → 过滤限流 → 投递通道 → 播放队列。逐段回答「为什么需要下一个」：
- 消息结构统一了才谈过滤——三类内容一条管道，分型处理而非分管道。
- 过滤挡住了滥用才敢广播——公共面的第一职责不是送达而是不出事。
- 限流兜住了才谈投递——在线推送与离线拉取分界清晰，公告才不漏人。
- 送达了才谈播放——队列与优先级是客户端的事，服务端保证有序到达即可。
上游：网络层的广播与推送（通道与推送机制）、结算（喇叭扣费凭证）；下游：任务系统与成就与图鉴（喇叭事件可被订阅）、运营侧活动公告（公告源，走马灯是展示面）。
Reference
- 本页为机制归纳；商业案例的喇叭定价与广播策略以各自官方公开信息为准。
- 敏感词与内容安全口径需结合发行地区监管要求，本页给的是通用分层做法。
- 术语对照：Marquee（走马灯）、Announcement（公告）、Shout/Horn（喇叭）、TTL（消息时效）、Rate Limit（限流）、Merge Window（合并窗口）。