群集环境中JMS主题的HTTP使用者

Question

我已经看到了这个问题的点点滴滴，但没有任何直接回答它。

这是假设的环境：

• 20个以Java为中心的服务器（即Tomcat / Glassfish / Jboss /等等） 通过HTTP与客户交谈
• 服务器前面的HTTP负载均衡器不保证 通过每个客户端连接将您带回同一服务器。
• 其他任何技术都是明智的。 （JMS / Camel / Memcached / Hazelcast / Whatever）

我们希望Joe和他的浏览器（可能使用Flash或HTML5或任何客户端技术）接收发布到所有20台服务器可用的JMS主题的所有消息。

以下是一个例子：

• Joe的第一个HTTP连接命中服务器A
• 服务器A现在有一个针对Joe的HTTP会话（通过cookie等）
• 服务器A订阅主题（基于他的会话ID等）
• Joe的HTTP连接结束。
• 会向主题发布消息。
• Joe建立另一个连接，但这次是由服务器F处理。

这对我来说有点模糊。

• 我们知道Joe在返回时的会话ID（也许会话在所有服务器上共享），但JMS订阅呢？如果服务器F必须再次为该主题订阅Joe，他是否只是错过了一条消息？是一个Joe可以从中检索该消息的唯一服务器，或者当他订阅F时会发生某种魔法并且它只知道他没有收到消息（大概是在A等待他）。

我想我有点不清楚“订阅”是什么（过程明智）以及它与集群服务器的关系。我正在使用长轮询（cometd）和websockets来帮助客户端响应接收主题消息，但是当有许多服务器可以处理连接和订阅时，必须考虑这将如何工作。我想避免服务器固定。

感谢您的任何指示。

EDIT1：希望有些澄清。我在这里提到的具体内容可以在BlazeDS框架中找到。它允许HTTP客户端订阅JMS主题并使用长轮询来实现近乎实时的客户端更新，但它要求一旦客户端命中服务器，所有请求必须返回到该服务器。所以它必须（不知何故？）在该服务器上保持该客户端的主题订阅活动。我想摆脱这个要求（使用任何技术/框架）。

Answer 1

JMS服务器会跟踪每个订阅，并在持久订阅与非持久订阅之间产生差异。假设您有客户A，B，C和主题T.

1. 客户端A订阅主题T并等待消息
2. 客户B订阅主题T等待消息
3. 客户端C对主题T进行Durable订阅并等待消息
4. 客户端B和C在将消息M放入主题T
之前几秒钟崩溃
5. 客户端A获取消息M的副本，因为它已订阅并且当前已连接到jms服务器
6. 客户端B重新启动但没有获得该消息的副本，因为当消息到达主题时它未连接到jms服务器
7. 客户端C重新启动并获取消息M，因为它提交了持久订阅，JMS服务器在C崩溃时保留了消息M的副本，并等待C返回并声明消息。

消息服务器上有管理设置来控制jms服务器等待持久订阅者返回并在将消息发送到死信队列之前声明消息的时间长度或者消息的最大数量。等待订阅者回来索赔的主题。你真的需要平衡永不松散的消息与流消息以及内存或磁盘空间不足。

请注意，持久队列的概念与持久订阅者的概念不同。持久队列和主题通过在确认收到消息之前将队列和消息的内容写入磁盘来保护您免受JMS服务器的崩溃。持久订阅者是关于在客户端未连接时消息到达时消息发生的情况。

---

老答案。

以您对SQL数据库的看法来思考JMS服务器。从Web容器的角度来看，应该有一个到JMS服务器的连接池，所以您要做的是获取与JMS服务器的连接并订阅主题。例如。

• JMS服务器有一个名为AddressChangeTopic的主题
• 每个tomcat实例都订阅了AddressChangeTopic
• Joe / Jim / John等的地址更改事件都转到相同的AddressChangeTopic而不是去JohnAddressTopic，JimAddressTopic，...等为每个用户创建一个单独的主题为应用程序是不切实际的你有100万用户，你会有100万个主题吗？

因此，如果正在使用一个主题，则必须使用选择性消费者使用该主题中的消息，请参阅http://www.eaipatterns.com/MessageSelector.html选择性消费者将执行的操作是来自符合特定条件的主题的反向消息。例如，向主题发布JMS消息的消息生成器应该包括头或称为targetUser的JMS属性或类似的东西，然后消费者可以说从AddressChangeTopic给出任何消息，其中自定义属性targetUser =“Joe”查看一些示例选择器示例Here

关键是要意识到您可以查询数据库表的方式查询队列或主题，但查询语法有限。从概念角度来看，我强烈推荐企业集成模式书http://www.amazon.ca/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683

Answer 2

Virtual Topics is exactly the solution I have been looking for.它描述了问题和解决方案（我用更简洁的词语:-)请参阅＆＃34; JMS持久性主题的限制＆＃34;