使用Websphere MQ客户端构建持久的体系结构

Question

如果客户端不允许您保留消息，也不允许确保交付，那么如何使用MQ客户端和服务器创建持久的体系结构环境？

如果客户端似乎不包含持久保存数据所需的任何必要组件，那么试着弄清楚如何构建可销售/持久的架构。

谢谢，

取值

Answer 1

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

在这20年间，导致创建MQSeries（现在的WebSphere MQ）的原始问题已基本解决。网络已经通过几个可用性和高可用性提高了硬件和软件集群，提供了保持不同组件24x7全天候可用的选项。

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

Answer 2

MQ的默认操作是在发送消息时（MQPUT或JMS术语producer.send），在消息到达队列管理器上的队列之前，应用程序不会在MQPUT调用上获得响应。即MQPUT是同步调用，如果您获得OK的完成代码，则表示客户端应用程序所连接的队列管理器已成功接收到该消息。它可能尚未达到其最终目的地，但它已经达到了MQ服务器的保护，因此您可以依靠MQ来管理消息并将其转发到需要它到达的位置。

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

有多种级别的邮件保护可用。 如果您正在使用非持久性消息和异步PUT，那么您实际上是说消息是否到达目的地并不重要（尽管它们通常会这样）。 如果您希望MQ真正关注您的消息，请使用如上所述的同步PUT，持久消息，并在事务（也称为syncpoint）中执行PUT和GET，这样您就可以对提交点进行完全的应用程序控制。

如果您的网络非常不可靠，以至于您经常无法将消息发送到服务器，并且需要定期重试，以至于需要客户端消息保护，您可以调查的一个选项是MQ遥测（例如，在WebSphere MQ V7.1中设计用于低带宽和/或不可靠的网络通信，作为进入更广泛MQ的路径。