我已经看到了这个问题的点点滴滴，但没有直接回答它。
这是假设的环境：
- 20 个以 Java 为中心的服务器（即 Tomcat / Glassfish / Jboss / 其他）通过 HTTP 与客户端通信
- 服务器前面的 HTTP 负载平衡器不能保证每次客户端连接都能将您带回同一台服务器。
- 其他任何东西都是可用的技术明智。（JMS / Camel / Memcached / Hazelcast / 不管）
我们希望 Joe 和他的浏览器（可能使用 Flash 或 HTML5 或任何客户端技术）接收发布到所有 20 个服务器都可用的 JMS 主题的所有消息。
这是一个例子：
- Joe 的第一个 HTTP 连接到达服务器 A
- 服务器 A 现在有一个针对 Joe 的 HTTP 会话（通过 cookie 等）
- 服务器 A 为他订阅主题（基于他的会话 ID 等）
- Joe 的 HTTP 连接结束。
- 一条消息发布到该主题。
- Joe 建立另一个连接，但这次它由服务器 F 处理。
这对我来说有点模糊。
- 我们知道 Joe 返回时的会话 ID（并且可能会话在所有服务器之间共享），但是 JMS 订阅呢？如果服务器 F 必须再次订阅 Joe 的主题，他只是错过了一条消息吗？A 是 Joe 可以从中检索该消息的唯一服务器，还是当他订阅 F 并且它只知道他没有收到消息时会发生某种魔术（大概在 A 上等待他）。
我想我有点不清楚“订阅”的作用（过程明智）以及它与集群服务器的关系。我正在使用长轮询（cometd）和 websockets 来帮助客户端在接收主题消息时响应，但是必须考虑当有许多服务器可以处理连接和订阅时这将如何工作。我想避免服务器固定。
感谢您的任何指示。
EDIT1：希望有所澄清。我在这里指的是 BlazeDS 框架中提供的特定内容。它允许 HTTP 客户端订阅 JMS 主题并使用长轮询来实现近乎实时的客户端更新，但它要求一旦客户端访问服务器，所有请求都必须返回到该服务器。因此，它必须（以某种方式？）保持该服务器上该客户端的主题订阅处于活动状态。我想摆脱这个要求（使用任何技术/框架）。