我正在开发一个将大量使用 JBoss Messaging (JMS) 的项目。我的任务是为其他开发人员围绕消息构建一个易于使用的包装器，并且正在考虑使用 JMS 的消息选择器来提供一种过滤技术，以将不必要的消息发送降至最低。我很好奇是否有人在性能方面有这样做的经验？我担心 JMS 提供者可能会陷入消息选择器的困境，从而有效地破坏了整个目的。但是，这比为每种消息类型创建一长串主题/队列要好得多。
毫无疑问，我最终会最终使用这两者的某种组合，但我担心无论我更倾向于哪种方式对性能的影响。
最佳答案
正如 Martin 提到的，默认情况下，大多数 JMS 实现将在客户端处理消息选择器，除非它们是持久订阅的一部分，而 大多数 JMS 实现将处理它们在服务器上也可以避免在通过选择器的消息数量显着减少时保留太多消息。某些系统(如 SonicMQ)允许您指定应在服务器上处理消息选择器，如果您的消息代理上可用 CPU 过多但消费者上没有可用的 CPU，这是一个不错的选择。
请记住，虽然基于主题的选择通常更快，但它可能相当麻烦，因为如果你想听 5 个不同的东西，你必须有 5 个不同的 MessageConsumer。幼稚驱动程序实现中的每一个都是不同的线程，并且可以开始累加。出于这个原因，从发布中支持两者通常很有用，这样一些客户端可以只收听他们想要的主题，而其他客户端可以使用消息选择器(或代码-基于选择器)。
但是，您应该始终针对您的应用程序和代理进行测试。每个代理处理情况的方式不同，每个应用程序的功能也不同。您不能只说“始终使用技术 X”，因为用于客户端导向消息处理的每种技术都有不同的权衡。基准，基准，基准。
使用消息选择器要记住的一点是，它们不能动态更改，因此您可能会丢失消息或不得不手动管理复杂的切换场景。想象一下以下用例:
- 您正在收听表单的消息选择器(Ticker in ('CSCO', 'MSFT'))
- 用户想开始收听 AAPL
- 您必须关闭旧的 MessageConsumer 并使用表单中的选择器启动一个新的 (Ticker in ('CSCO, 'MSFT', 'AAPL'))
- 在切换期间，您要么丢失消息(因为您在启动新消息之前关闭了旧消息)，要么您必须手动删除重复消息(因为您在旧消息之前启动了新消息)
关于java - JMS 消息传递性能 : Lots of Topics/Queues vs. 广泛过滤(消息选择器)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/587899/