集群环境中JMS主题的HTTP消费者

我看到了这个问题的一些片段，但没有什么能直接回答这个问题。

下面是假设的环境:

20个以Java为中心的服务器(如Tomcat/Glassfish/Jboss等)通过HTTP
服务器前面的HTTP负载均衡器不保证在每次客户端连接时将您带回到同一服务器。
其他任何技术都是可用的。(JMS/Camel/Memcached/Hazelcast/Whatever)

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

下面是一个例子:

Joe的第一个HTTP连接到达服务器A
服务器A现在有一个HTTP会话Joe(通过cookie等)
服务器A订阅他的主题(基于他的会话ID或类似的)
Joe的HTTP连接结束
向主题发布消息。
Joe建立了另一个连接，但这次是由服务器f处理的。

对我来说这就是事情变得有点模糊的地方。

我们知道Joe返回时的会话ID(可能会话在所有服务器之间共享)，但是JMS订阅呢?如果服务器F必须再次向Joe订阅该主题，他是不是错过了一条消息?A是Joe唯一可以从中获取消息的服务器吗?或者当他订阅F时，是否会发生某种神奇的事情，并且它只知道他没有收到消息(可能在A上等待他)?

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

谢谢你的指点。

编辑1:希望得到一些澄清。我在这里指的是BlazeDS框架中可用的一些特定的东西。它允许HTTP客户机订阅JMS主题，并使用长轮询实现近乎实时的客户机更新，但是它要求客户机一旦访问服务器，所有请求都必须返回到该服务器。因此，它必须(以某种方式?)为该服务器上的该客户机保持主题订阅活动。我想摆脱这种需求(与任何技术/框架)

JMS服务器跟踪所做的每个订阅，并区分持久订阅和非持久订阅。假设您有客户端A、B、C和一个主题t。

客户端A订阅主题T并等待消息
客户端B订阅主题T等待消息
客户端C向主题T发送持久订阅并等待消息
客户端B和C在消息M放到主题T前几秒崩溃
客户端A获得消息M的副本，因为它已订阅并且当前已连接到jms服务器
客户端B重新启动，但没有获得消息的副本，因为当消息到达主题
客户机C重新启动并获得消息M，因为它传递了持久订阅，当C崩溃并等待C返回并声明消息时，JMS服务器保留了消息M的副本。

消息服务器上有管理设置，用于控制jms服务器在将消息发送到死信队列之前等待持久订阅者返回并声明消息的时间长度，或者控制等待订阅者返回并声明的主题上的最大消息数。您确实需要平衡永不丢失消息与流消息和耗尽内存或磁盘空间之间的关系。

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

老回答。

像考虑SQL数据库那样考虑JMS服务器。从web容器的角度来看，应该有一个到JMS服务器的连接池，因此您要做的就是获取到JMS服务器的连接并订阅主题。例如,

JMS服务器有一个名为AddressChangeTopic的主题
每个tomcat实例都有一个订阅AddressChangeTopic

因此，如果正在使用一个主题，则必须使用选择性消费者来消费来自该主题的消息，请参阅http://www.eaipatterns.com/MessageSelector.html选择性消费者将从符合特定标准的主题检索消息。例如，将JMS消息发布到主题的消息生产者应该包括一个header或一个名为targetUser的JMS属性或类似的东西，然后消费者可以说给出来自AddressChangeTopic的任何消息，其中自定义属性targetUser="Joe"参见一些示例选择器示例在这里

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

虚拟主题正是我一直在寻找的解决方案。它描述了问题和解决方案(用我所拥有的更简洁的语言:-)，参见"JMS持久主题的限制"

相关内容

最新更新

热门标签：