JMS消息传递性能:大量主题/队列与广泛过滤(消息选择器)

我正在开发一个将大量使用JBoss Messaging(JMS)的项目.我的任务是为其他开发人员构建一个易于使用的Messaging包装器,并且正在考虑使用JMS的Message Selectors来提供过滤技术,以便将不必要的消息发送保持在最低限度.我很好奇是否有人在表演方面有任何经验？我担心JMS提供商可能会陷入消息选择器的困境,从而有效地破坏了整个目的.然而,它比为每种消息类型创建一长串主题/队列要好得多.

最终,我无疑会最终使用两者的组合,但我关注的是对性能的影响,无论我更倾向于哪种方式.

正如Martin所提到的,默认情况下,大多数JMS实现将在客户端上处理消息选择器,除非它们是持久订阅的一部分,当大多数 JMS实现将在服务器上处理它们时,以避免在显着减少时过多的消息被持久化在通过选择器的消息数量中.某些系统(如SonicMQ)允许您指定应在服务器上处理消息选择器,如果您的消息代理上有多余的CPU可用而不是消费者,则这是一个很好的选择.

请记住,虽然基于主题的选择通常更快,但它可能非常麻烦,因为如果你想听5种不同的东西,你必须有5个不同的MessageConsumers.天真的驱动程序实现中的每一个都是一个不同的线程,并且可以开始加起来.出于这个原因,从发布中支持两者通常是有用的,这样一些客户端只能监听他们想要的主题,而其他客户端可以使用消息选择器(或代码 - )来监听他们想要的主题层次结构(例如foo.#).基于选择者).

但是,您应该始终针对您的应用程序和经纪人进行测试.每个经纪人处理不同的情况,每个应用程序的功能都不同.你不能只说"总是使用技术X",因为用于客户端的消息处理的每种技术都有不同的权衡.基准,基准,基准.

消息选择器要记住的一件事是它们不能动态更改,因此您可能会丢失消息或不得不手动管理复杂的切换方案.想象一下以下用例:

您正在收听表单的消息选择器(Ticker in('CSCO','MSFT'))

用户想要开始收听AAPL

您必须关闭旧的MessageConsumer并使用表单中的选择器启动一个新的MessageConsumer(Ticker in('CSCO,'MSFT','AAPL'))

在切换期间,您要么丢失消息(因为您在启动新消息之前关闭了旧消息),要么必须手动删除重复消息(因为您在旧消息之前启动了新消息)

我的两分钱:

我问自己与ActiveMQ完全相同的问题.

首先,我没有使用选择器并创建了许多主题.由于经纪人在没有大量资源的情况下无法处理100个主题,因此表现非常糟糕.

然后我使用了主题/选择器的组合.我现在有少量话题.选择很好.但负载不是很重,不超过10 msg/s

我确实开发了一个抽象层,允许开发人员在不提出问题的情况下进行编码,我们通过切换实现来进行测试.