考虑Mercure Hub服务器负载的更优消息推送方案选型咨询

针对你提到的两种推送方案，以服务器负载优化为核心目标的话，绝大多数场景下方案2（元素级独立主题定向推送）表现更优，具体对比分析如下：

两种方案的负载开销差异 #

方案1（通用主题全量广播）的问题 #

• 服务器侧开销极高：每产生一条推送消息，Mercure Hub需要向所有订阅了通用主题的在线用户全量广播。如果你的在线用户有10万，单条消息就要触发10万次推送动作，CPU、内存、出口带宽消耗会随在线用户数线性上涨，推送频率稍高就很容易把Hub资源打满。
• 额外浪费客户端资源：用户端会收到大量和自己无关的无效推送，需要额外做过滤逻辑，无端消耗客户端算力和流量，移动端场景下用户感知会非常明显。

方案2（元素级独立主题定向推送）的优势 #

• 服务器侧开销极低：Mercure Hub只会把消息推送给实际订阅了对应主题的用户，比如某条元素更新仅对应100个订阅用户，单条消息仅需推送100次，资源消耗相比方案1能降低几个数量级。Mercure原生对多主题管理做了性能优化，主题匹配的额外开销可以忽略不计。
• 客户端无额外消耗：用户只会收到自己关注的内容，不需要做冗余的过滤逻辑，客户端性能表现更好。

特殊场景下的方案选择 #

如果你的业务同时满足以下所有条件，也可以选择方案1：

• 推送内容基本都是全局广播性质，90%以上的在线用户都需要接收
• 整体用户规模小，比如内部工具类应用，在线用户长期不超过1000人
• 推送频率极低，单日推送条数不超过10条

方案2的优化建议 #

实际使用方案2时可以进一步降低负载：

• 做主题层级化设计，比如按/topic/项目ID/资源类型/资源ID的规则定义主题，配合Mercure的通配符订阅能力，用户需要订阅某类资源全量更新时直接订阅通配符主题即可，不需要逐个订阅单元素主题。
• 订阅阶段做好权限校验，避免用户订阅无权限访问的主题，减少无效订阅占用的Hub资源。

内容的提问来源于stack exchange，提问作者Tom