4

如果客户端不允许您保留消息,也不允许确保传递,您如何使用 MQ 客户端和服务器创建持久的架构环境?

只是想弄清楚如果客户端似乎不包含持久化数据所需的任何必要组件,您如何构建可销售/耐用的架构。

谢谢,

小号

4

2 回答 2

4

中间件消息传递源于需要在本地保存数据以减轻远程节点或网络故障的影响。当时的想法是队列管理器本地安装在应用程序所在的盒子上,并被视为传输堆栈的一部分。例如,您可以将 TCP 和 WMQ 安装为传输,并且某些应用程序会使用 TCP,而其他应用程序会使用 WMQ。

在其间的 20 年中,导致创建 MQSeries(现在的 WebSphere MQ)的最初问题已基本解决。网络的可用性提高了 9 倍,高可用性硬件和软件集群提供了选项以保持不同的组件 24x7 可用。

因此,当今广泛用于解决您的问题的做法遵循两种基本方法。要么使组件具有高可用性,以便客户端始终可以找到消息传递服务器,要么将 QMgr 放在应用程序所在的位置以提供本地队列。

于 2012-05-01T15:25:46.157 回答
1

MQ 的默认操作是,当发送消息(MQPUT 或 JMS 术语 producer.send)时,应用程序在消息到达队列管理器上的队列之前不会收到对 MQPUT 调用的响应。即MQPUT是同步调用,如果收到完成码OK,说明客户端应用程序连接的队列管理器已经成功接收到消息。它可能还没有到达它的最终目的地,但它已经达到了 MQ 服务器的保护,因此您可以依靠 MQ 来处理消息并将其转发到它需要到达的地方。

无论是客户端连接还是本地绑定到队列管理器,发送消息的应用程序都对其数据负责,直到 MQPUT 调用成功返回。类似地,接收应用程序一旦从成功的 MQGET(或 JMS consumer.receive)调用中获取数据,就需要对其数据负责。

有多个级别的消息保护可用。如果您使用的是非持久性消息和异步 ​​PUT,那么您实际上是在说消息是否到达目的地并不重要(尽管它们通常会)。如果您希望 MQ 真正照顾您的消息,请使用如上所述的同步 PUT、持久消息,并在事务(也称为同步点)中执行您的 PUT 和 GET,这样您就可以完全控制提交点。

如果您的网络非常不可靠,以至于您希望定期无法将消息发送到服务器,并且希望需要定期重试以便需要客户端消息保护,那么您可以研究的一个选项是 MQ Telemetry(例如在 WebSphere MQ 中) V7.1) 设计用于低带宽和/或不可靠的网络通信,作为进入更广泛 MQ 的路由。

于 2012-05-02T16:09:47.900 回答