SpringBoot集群中以Redis为消息代理的WebSocket上STOMP同步方案咨询

集群WebSocket互联的主流最佳实践 #

目前生产环境公认的最优方案是中心化共享消息代理架构，其他替代方案都存在明显的适用限制：

• 共享消息代理方案：所有集群节点连接同一个中心化的消息中间件，广播消息先统一发送到中间件，再由中间件转发到所有订阅了对应主题的集群节点，最后由节点推送给自身持有的客户端连接。该方案不需要维护节点间的点对点互联，扩展性、容错性最好，是大规模集群的首选
• 节点对等互联方案：每个节点和其他所有节点建立专属连接同步广播消息，仅适合3节点以下的极小集群，节点数量上升后互联复杂度会指数级增长，生产环境不推荐
• 粘性会话+跨节点调用方案：依赖负载均衡粘性会话将同一用户绑定到固定节点，广播时通过服务发现调用所有节点的本地广播接口，容错性差、调用链路长，仅适合临时过渡使用

Redis作为STOMP消息代理的可行性 #

Redis本身原生不支持STOMP协议，但你完全可以基于Redis现有能力实现和STOMP代理等价的集群广播效果，不需要额外引入RabbitMQ，适配你现有技术栈的改造成本极低：

• 如果你需要完整使用STOMP协议的全量特性，可以引入第三方Redis STOMP协议适配层，不需要调整现有业务代码即可完成切换
• 如果你不需要强依赖STOMP的专属特性，更推荐用最小改造方案：
  1. 保留你现有单节点环境的WebSocket连接、客户端订阅逻辑完全不变
  2. 所有集群节点新增对Redis指定Channel的订阅监听
  3. 业务端需要发送集群广播时，先把消息推到Redis对应Channel，不要直接推送给本地客户端
  4. 所有集群节点收到Redis Channel的消息后，再调用本地的SimpMessagingTemplate推给自身连接的所有订阅了对应主题的客户端
• 可靠性适配：如果你的业务允许极小概率的消息丢失（Redis Pub/Sub为发后即忘逻辑，节点离线期间的消息无法追溯），直接用Redis Pub/Sub即可；如果需要消息持久化、确保送达，可以用Redis 5.0+的Stream数据结构替代Pub/Sub，可靠性接近RabbitMQ

很多教程推荐RabbitMQ的核心原因是RabbitMQ原生支持STOMP协议，Spring WebSocket可以零代码对接第三方STOMP代理，但这不是必须选择。只要能实现「所有节点同步收到广播消息再转发给本地客户端」的核心逻辑，用你现有技术栈的Redis完全可以满足需求，还能省去额外维护RabbitMQ集群的运维成本。

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