WebSocket整合Spring、SockJS、Stomp、Rabbitmq分布式多实例消息推送

这门课解决的是一个很具体的问题：你的系统里已经有消息推送，单机跑得好好的，一上多实例就开始丢消息、串会话、连不上。如果你正卡在这里，或者准备做推送但不想踩一遍坑，这门课值得花时间。

先确认自己缺的是哪一块

推送这件事，很多人以为自己缺的是「WebSocket 怎么写」。真到生产环境会发现，握手协议本身只是最上面一层。往下还有：浏览器不支持原生 WebSocket 时怎么退回轮询、前端怎么订阅和退订不同频道、后端怎么把一条消息准确送到某个用户而不是广播给所有人、多台服务器之间怎么让消息互通。

对照一下，如果你有以下任意一种情况，说明缺口在链路的某一环：

• 会用 @ServerEndpoint 写单机推送，但说不清 SockJS 在什么场景下才需要。
• 听说过 STOMP，但只会照抄 /topic、/queue、/app 这几个前缀，讲不出它们各自的语义差别。
• 把应用部署成两个实例后，A 实例上的用户收不到 B 实例推的消息，只能靠临时改成广播绕过。
• 没有考虑过重连、断线期间的消息补偿、订阅关系失效这些问题。

这门课的技术链路是怎么串的

它把四个东西放在一条线上讲，而不是拆成四个孤立的知识点。WebSocket 负责建立长连接，SockJS 负责在连接不可用时提供退路，STOMP 负责在连接之上定义一套可读的订阅与发送语义，RabbitMQ 负责把消息从单个实例扩展到多实例。

关键在于最后一环。单机推送时，会话存在本机内存里，直接遍历发就行；一旦变成多实例，任何人都可能持有目标用户的连接，本地内存完全不够用。这时需要引入一个外部的消息中间件，让每个实例都订阅，由它来分发。理解了这一点，你才明白为什么前面的 STOMP 要被当作消息协议的载体，而不是仅仅当成一层封装。

配套练习多半会卡在这些地方

光看代码能懂，自己动手就容易出问题，主要集中在几处：心跳与超时配置不当导致连接被中间层掐断；跨域和代理层（Nginx 等）没做升级头透传，握手直接失败；订阅路径与消息目的地的映射写错，消息发出去没人收；多实例场景下忘了配置外部代理，仍然在用内存代理。

练习时建议按顺序推进：先把单实例的握手、订阅、点对点发送跑通，再引入消息中间件改成多实例，最后补可靠推送相关处理。每一步都验证一次「关掉其中一个实例后，消息是否还能到」，比一次性全写完更容易定位问题。

学完之后应该能回答的问题

• 什么情况下必须用 SockJS，什么情况下可以直接用原生 WebSocket？
• STOMP 里的订阅地址和发送地址为什么要分开设计？用户级别的消息和广播消息在地址上如何区分？
• 两个应用实例同时在线时，一条发给特定用户的消息，最终是怎么找到那条连接并把数据写出去的？
• 用户断线重连后，之前的订阅关系还需要恢复吗？谁负责这件事？
• 用内存代理和用外部代理，分别会带来哪些限制？

如果这些问题你现在答不上来，学完能答上来，这门课的目的就达到了。如果你的推送还停留在单机、且近期没有扩容计划，可以先只补 SockJS 和 STOMP 的部分，RabbitMQ 那一环等真正需要时再回头看。