【问题标题】:Can MQ Support Multiple Separate Clients for the Same Queue While Maintaining Independent Messaging?MQ 能否在保持独立消息传递的同时支持同一队列的多个单独客户端?
【发布时间】:2021-08-03 01:02:09
【问题描述】:

我们有多个应用程序环境(开发、QA、UAT 等)需要通过 MQ 连接到更少的提供程序环境。例如,提供者只有一个测试(我们称之为 TEST1)环境,所有客户端应用程序环境都需要与之交互。每个客户端环境必须只接收对相应环境发送的消息的 MQ 响应。这是一个大容量场景,因此已排除关联消息 ID。

现在 TEST1 设置了一个队列并且可以正常工作,但是如果客户端应用程序的一个环境想要使用它,则必须关闭其他环境,以免消息重叠。

MQ 是否支持让多个客户端连接到单个队列同时保留特定于客户端的消息传递的模型?如果是这样,控制在哪里(即通道、队列管理器等)?如果不是,唯一的解决方案是为每个对应的客户端设置额外的队列吗?

【问题讨论】:

  • 请求/回复,其中回复的相关ID 填充了请求消息ID 通常是您将如何处理您所说的不可接受的方式。如果消息中的某些内容允许您判断它应该是哪个实例,您可以编写一个中间应用程序来读取传入消息并将它们写入适当的实例特定队列。

标签: ibm-mq


【解决方案1】:

多年来,我一直在使用 IBM MQ,在这个问题上反复讨论。我得出的结论是,共享队列只会让生活变得更加困难。队列应该像万圣节的糖果一样分发。如果应用程序团队说他们的应用程序有 10 个组件,那么 MQAdmin 应该给他们 10 个队列。对于队列管理器或服务器或 CPU 或硬盘,资源使用没有区别。

此外,使用有意义且易于应用安全性的 MQ 命名标准。即用于 HR(人力资源)部门

  • HR.PAYROLL.SALARY
  • HR.PAYROLL.DEDUTIONS
  • HR.PAYROLL.BENEFITS
  • HR.EMPLOYEE.DETAILS
  • HR.EMPLOYEE.REVIEWS
  • 等等……

【讨论】:

    【解决方案2】:

    您可以使用诸如MQGET(where applname="myapp") 之类的选择器或基于特定的用户定义属性(假设发送者填充了此类属性),但这可能比通过 msgid 或 correlid 进行的任何检索性能都差。尽管您没有提供任何信息来证明 get-by-correlid 实际上是有问题的。

    当然,测试和生产环境之间的任何差异——无论是涉及代码还是配置——都将是非常危险的。

    您通常不会在多个不同的应用程序类型之间共享一个目标队列 - 多个队列更加标准。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-09-11
      • 2014-05-08
      • 2016-11-18
      • 1970-01-01
      • 1970-01-01
      • 2021-09-21
      • 1970-01-01
      相关资源
      最近更新 更多