java - WebSphere MQ 低延迟消息传递 - 它是否具有 JMS（或类似 JMS）API？

Question

我们目前正在通过 JMS 使用 IBM MQ，但似乎推送的消息超出了它的处理能力 - 奇怪的是，问题似乎是间歇性的。

消息是价格，因此不需要保证，只需要快速发送即可。

由于 IBM 有一个低延迟产品，我想知道这是否可能是更好的解决方案 - 但它似乎没有 JMS api，或者至少不容易看到。

任何人都知道低延迟产品中是否有 JMS api，或者它确实具有的“独特”API 是否类似于 JMS...

或者，MQ调整的指针也将不胜感激...... :)

Answer 1

绝对是低延迟消息传递产品更适合您的问题，我正在开展一个项目，我们使用来自29West的称为 LBM 的低延迟消息传递产品做一些非常相似的事情。它没有 JMS api，我怀疑低延迟空间中的大多数产品都没有。与这些类型的产品（例如持久性、选择器等）结合使用时，存在大量没有意义的特性。我们发现在消息传递产品之上编写我们自己的简单 api 相当容易，并且可以灵活地在以后更改产品，并将我们从 JMS api 的一些庞大和冗长中解脱出来。

另一个要考虑的选择是JGroups。

29West 在其消息传递产品线中添加了 JMS 支持。

Answer 2

关于“MQ 调优指针”，在SupportPacs 页面上有每个平台的性能评估和具体建议。向下滚动到名为 MP* 的 SupportPacs 并查找适当的版本和平台。使用大小消息、持久和非持久消息、getter 和 putter 数量的变化等测试了各种场景。

Answer 3

作为 LLM 产品的前开发人员，我可以说它做到了，或者至少做到了。请参阅下面的摘录，我从 2.6 版的公开信息中心摘录

也就是说，我记得 MQ 的全部意义在于保证交付。这是有时间和地点的，但它是以延迟和带宽为代价的。

LLM 从根本上具有不同的目的；它有可靠的交货：也就是说，如果它无法交付，您只会知道它未能交付。这些消息的可恢复性仅受您愿意保留多少缓存或从磁盘召回以及因此您愿意在等待恢复过程中等待恢复多长时间的限制。在您的情况下，您可能不关心恢复。LLM 是否适合您，我无法推测。我能说的是，从我作为过去的开发人员和后来的客户的角度来看，我发现两者之间几乎没有相似之处，而且这种应用程序的 LLM 性能完全将 MQ 吹得水泄不通。我也从未经常使用 java/jms 方面，而是专注于 C/C++，所以对此持保留态度。我只知道它做到了，并且在谷歌中查找。

http://www-01.ibm.com/support/knowledgecenter/SSQPD3_2.6.0/com.ibm.wllm.doc/api/javadoc/messaging/com/ibm/llm/jms/package-summary.html

包 com.ibm.llm.jms 描述

为 LLM JMS 客户端实现提供者特定的公共类。

JMS 中使用的大多数接口都是由通用 JMS 接口定义的。但是，JMS 规范不包括配置 JMS 客户端所需的类和接口。

有关 JMS 类和方法的信息，请参阅 JMS API 文档。

介绍

LLM JMS 客户端为 LLM 提供 Java 消息服务 (JMS) 接口。使用 LLM 的 JMS 接口允许与其他消息传递提供程序的通用接口，并通过允许开发人员使用他们熟悉的接口来加速应用程序开发。使用 JMS 接口最适合使用可以集中管理设置的通用消息传递功能的应用程序。这包括许多传统的客户端应用程序。在应用程序依赖于 LLM 特定功能或需要与 LLM 进行大量应用程序交互的情况下，LLM JMS 客户端无法正常工作。虽然使用 JMS 接口会增加一些延迟，但它仍然提供非常低的延迟和高吞吐量的消息传递。

LLM JMS 客户端支持大部分LLM 客户端功能，但不支持在层内运行的服务器功能，或者作为负载平衡传输器。

LLM 基于直接生产者到消费者的消息传递。JMS 通常使用消息服务器实现，而需要消息服务器的 JMS 功能在使用 LLM JMS 客户端时不可用。这包括所有点对点消息传递（队列）以及恢复功能。LLM JMS 客户端设计为在 JSE 环境中运行，不支持应用程序服务器扩展或 XA 事务。

LLM JMS 客户端如何实现 JMS

LLM JMS 客户端使用不对外公开的实现类来实现每个基本 JMS 对象。这些对象的子类使用相同的实现类来实现。这意味着只有两个管理对象，ConnectionFactory 和 Destination。LLM 定义的 ConnectionFactory 可以转换为 TopicConnectionFactory 和 QueueConnectionFactory，而 LLM 定义的 Destination 可以转换为 Topic 和 Queue。Connection、Session、MessageProducer 和 MessageConsumer 也是如此。来自一个提供商的 Destination 对象必须与同一提供商的 Connection 一起使用。但是，可以将一个 JMS 提供者生成的消息发送到另一个 JMS 提供者。

LLM JMS 客户端不实现点对点消息传递模型（队列），但可以创建所有 JMS 对象。

LLM JMS 客户端需要至少 Java 5 的 JVM。

LLM JMS 客户端定义了所有六种消息类型对象（Message、BytesMessage、MapMessage、ObjectMessage、StreamMessage 和 TextMessage）。当从 JMS 向 JMS 发送消息时，JMS 标头指示消息的类型。如果缺少 JMS 标头（这在从非 JMS 生产者发送消息时很常见），则 LLM JMS 客户端会尝试从内容中推断出消息的类型。通常消息将显示为 BytesMessage，但如果消息以 UTF-8 BOM 开头或显示为 XML，它将被解释为 TextMessage。TextMessages 被假定为 UTF-8 编码......