IBM MQ常用于金融系统, 提供了可靠的消息传递、事务管理、实时数据处理、系统集成和安全性保密性等功能，使得金融系统可以高效、安全地进行交易处理和数据传输。

基础

IBM MQ 是一种消息队列(类比kafka)，支持在应用程序，系统，服务和文件之间交换信息。提供了许多功能和特性来满足不同的企业消息传递需求。以下是 IBM MQ 中一些重要的队列特性：

点对点和发布订阅模式
消息持久化
事务管理
支持高可用部署(主从复制)
可集群化部署，构建高可用、高性能、可扩展的消息传递架构

核心概念与对象

配置应用举例

下面通过一个例子说明在mq中如何应用这些核心概念

首先看看MQ1 和 MQ2 对象的定义

QM1:  # 本地实例队列管理器中对象定义
----
DEFINE QREMOTE (QR) # 定义一个远程队列 QR
RNAME (QL)          # 在远程实例的队列名字为 QL
RQMNAME (QM2)       # 在远程实例的队列管理名字为 QM2
XMITQ (QT)          # 定义远程队列的传输队列(本地队列的一种)为QT
REPLACE 

DEFINE QLOCAL (QT)  # 定义一个本地队列
USAGE (XMITQ)       # 类型为传输队列
REPLACE 

DEFINE CHANNEL (C_QM1.QM2)  # cs名字，需要与QM2的接受channel(cr) 名字保持一直
CHLTYPE (SDR)
TRPTYPE (TCP)
CONNAME ('192.255.10.1 (1416)')  # 定义channel 发送地址
XMITQ (QT)                    # channel 负责发送的传输队列是QT
REPLACE


QM2: # 远程实例队列管理器中对象定义(ip为192.255.10.1)
---- 
DEFINE QLOCAL (QL)  # 定义一个普通的本地队列
REPLACE 

DEFINE CHANNEL (C_QM1.QM2) # 定义一个接受类型的channel
CHLTYPE (RCVR)
TRPTYPE (TCP)
REPLACE

生产客户端应用产生消息通过MQI API 发生给 QM1的QR队列
QR是远程队列，实际上消息被放到它的传输队列QT中(消息头记录远程管理器和队列的名字)
MCA程序(channel通讯执行实体)监听到channel cs(C_QM1.QM2)对应的传输队列有消息，将消息发给CONNAME (‘192.255.10.1 (1416)’) 远程实例
远程实例MCA程序收到消息，发现channel名字匹配本实例存在的channel名字，获取消息头中的远程管理器和队列的名字
判断存在对应管理器QM2，查找管理器中存在本地队列QL, 消息被放置到QL本地队列中
消费客户端通过MQI API 获取QM2中QL队列消息进行处理

部署运行

使用docker方式部署运行

docker run 
   --name ${CONTAINER_NAME} 
  --env LICENSE=accept 
  --env MQ_QMGR_NAME=QM1  # 创建默认的队列管理器 QM1
  --publish 1414:1414 
  --publish 9443:9443 
  --detach 
  icr.io/ibm-messaging/mq

在创建docker时可以挂载带有MQSC脚本(可以有多个)文件到容器的 /etc/mqm/目录下，配置MQ对象(队列，通道等)

# mqsc目录下有脚本20-config.mqsc，内容为:
DEFINE QLOCAL(MY.QUEUE.1) REPLACE  # 创建本地队列 MY.QUEUE.1
DEFINE QLOCAL(MY.QUEUE.2) REPLACE  # 创建本地队列 MY.QUEUE.2

docker run 
   --name ${CONTAINER_NAME} 
  --env LICENSE=accept 
  --env MQ_QMGR_NAME=QM1 
  --publish 1414:1414 
  --publish 9443:9443 
  --detach 
  --volume ${PWD}/mqsc/20-config.mqsc /etc/mqm/20-config.mqsc
  icr.io/ibm-messaging/mq

控制管理

在部署运行完后，可以使用控制与管理命令对mq进行配置。控制针对的是 MQ 部件(Queue Manager，命令服务器等 ), 管理针对的是MQ 对象(Queue，channel等)。有多种方式可以执行控制和管理命令：

命令行工具：IBM MQ 提供了 crtmqm、runmqsc 等命令行工具，你可以在命令行中使用它来执行各种命令

docker exec -it ${CONTAINER_NAME} bash  # 打开一个 bash shell
crtmqm QM1 #创建一个加QM1的 队列管理器
echo "DEFINE QLOCAL('MyQueue')" | runmqsc ${MQ_QMGR_NAME}  # 运行runmqsc脚本创建队列 MyQueue

MQSC 脚本：你可以将一系列的 MQSC 命令写入一个文件，然后使用 runmqsc 命令行工具来执行这个文件。例如：

runmqsc ${MQ_QMGR_NAME} < mqsc_script.mqsc

IBM MQ 控制台：使用web管理器查看和管理mq配置，访问地址、账号密码如下

https://ip:9443/
User: admin
Password: passw0rd
程序接口: IBM MQ 提供了各种语言的程序接口（例如 Java、C、.NET 等），你可以在你的应用程序中使用这些接口来执行各种命令。

高可用

IBM-MQ 高可用通过两方面来保证：消息持久化和高可用部署。

消息持久化

当消息生产者发生消息时通过使用 MQMD 结构的 Persistence 字段设置MQPER_PERSISTENT以将消息定义为持久性，IBM-MQ收到消息后就会将消息写入日志和队列数据文件。如果队列管理器在发生故障后重新启动，会在必要时从已记录的数据中恢复这些持久消息。
在 IBM MQ 中，消息的持久化是通过日志机制实现的。当一个持久性消息被发送到队列中时，IBM MQ 会将这个消息写入到日志中。然后，IBM MQ 会定期将日志中的消息刷新到磁盘中。这个过程被称为刷盘。
可以通过设置队列管理器的日志写入模式（Log Write Mode）来调整刷盘的间隔。你可以使用以下的命令来设置日志写入模式，请注意，刷盘间隔会影响到 IBM MQ 的性能(官网对比的性能数据)需要根据实际需求来权衡性能和数据安全性。

runmqsc <QueueManagerName> ALTER QMGR CHLAUTH(DISABLED) LOGBUFSZ(4096) LOGPRIMARY(10) LOGSECONDARY(20) LOGWRTINT(0)

<QueueManagerName> 是队列管理器的名称，LOGWRTINT(0) 是日志写入间隔，单位是毫秒。将日志写入间隔设置为 0，这意味着 IBM MQ 会在每次接收到持久性消息时立即将其写入到磁盘中。

高可用部署

多实例队列管理器

通过共享队列管理器数据和日志文件的任务在两台或多台计算机上配置的同一队列管理器的实例。启动多个实例，一个实例将成为活动实例，而其他实例将成为备用实例。如果活动实例发生故障，那么在另一台计算机上运行的备用实例将自动接管。

优点：

基于 IBM MQ配置自己的高可用性消息传递系统，而不需要 HACMP 或 MSCS 之类的集群技术。

不足：

结合其他机制切换ip地址
需要共享磁盘

部署步骤：

创建数据和日志文件的共享。
在一台服务器上创建队列管理器。
在第一个服务器上运行命令 dspmqinf 以收集队列管理器配置数据并将其复制到剪贴板。
使用复制的数据运行命令 addmqinf 以在第二个服务器上创建队列管理器配置。

HA 集群

HA 集群是由两台或更多台计算机和资源 (例如磁盘和网络) 组成的组，这些计算机和资源连接在一起并以这样的方式进行配置: 如果发生故障，那么高可用性管理器 (例如 HACMP ( UNIX® )) 或 MSCS ( Windows ) 执行故障转移。故障转移将应用程序的状态数据从发生故障的计算机传输到集群中的另一台计算机，并在那里重新启动它们的操作。这将提供在 HA 集群中运行的服务的高可用性。

HA 集群包含以下功能:

协调多个资源 (例如应用程序服务器或数据库) 的能力
更灵活的配置选项，包括包含两个以上节点的集群
可以多次故障转移，无需操作员干预
在故障转移过程中接管队列管理器的 IP 地址

不足(限制):

需要额外的产品购买和技能
需要可在集群节点之间切换的磁盘
HA 集群的配置相对复杂
故障转移在历史上是相当缓慢的，但最近的 HA 集群产品正在对此进行改进
如果用于监视资源 (例如队列管理器) 的脚本中存在缺陷，那么可能会发生不必要的故障转移

高可用性复制数据队列管理器 (HA RDQM)

RDQM 配置由在高可用性 (HA) 组中配置的三台服务器组成，每台服务器都具有一个队列管理器实例。其中一个实例是运行中的队列管理器，可将其数据同步复制到另外两个实例。如果运行此队列管理器的服务器发生故障，那么另一个队列管理器实例就会启动，并且具有可操作的最新数据。队列管理器的三个实例可以选择共享浮动 IP 地址，因此只需要使用单个 IP 地址来配置客户机。服务器的分组由 Pacemaker控制，复制由 DRBD 控制。

优点：

高可用性：HA RDQM 可以在多个节点上运行，如果一个节点失败，其他节点可以接管，从而提供了高可用性。
数据持久性：HA RDQM 使用了数据复制技术，可以在多个节点上存储相同的数据，从而提供了数据持久性。
故障转移：HA RDQM 支持自动和手动的故障转移，可以在节点失败时自动切换到其他节点，或者在需要时手动切换到其他节点。

不足：

复杂性：HA RDQM 的配置和管理比单节点的队列管理器更复杂，需要更多的管理工作。
性能：由于数据需要在多个节点之间复制，HA RDQM 可能会有一定的性能开销。
硬件要求：HA RDQM 需要多个节点来运行，这可能会增加硬件成本。

故障恢复复制数据队列管理器 (DR RDQM)

队列管理器在一个站点的主节点上运行，而该队列管理器的辅助实例位于另一个站点的恢复节点上。在主实例和辅助实例之间复制数据，如果主节点由于某种原因而丢失，那么可以将辅助实例制作成主实例并启动。

优点：

故障恢复：DR RDQM 可以在远程的备份站点上运行，如果主站点发生故障，备份站点可以接管，从而提供了故障恢复能力。
数据持久性：DR RDQM 使用了数据复制技术，可以在主站点和备份站点上存储相同的数据，从而提供了数据持久性。
故障转移：DR RDQM 支持自动和手动的故障转移，可以在主站点发生灾难时自动切换到备份站点，或者在需要时手动切换到备份站点。

不足：

复杂性：DR RDQM 的配置和管理比单节点的队列管理器更复杂，需要更多的管理工作。
性能：由于数据需要在主站点和备份站点之间复制，DR RDQM 可能会有一定的性能开销。
硬件要求：DR RDQM 需要在远程的备份站点上运行，这可能会增加硬件成本和网络带宽的需求。

故障恢复/高可用性复制数据队列管理器 (DR/HA RDQM)

结合了灾难恢复复制数据队列管理器 (DR RDQM) 和高可用性复制数据队列管理器 (HA RDQM) 的优点，提供了灾难恢复能力和高可用性。同时存在复杂性高，性能开销大和硬件要求高等问题。

云原生部署(Native HA)

Native HA 由三个节点 (例如，可以是三个 Kubernetes pod) 组成，每个节点都具有队列管理器的实例。一个实例是活动队列管理器，处理消息并写入其日志。每当写入日志时，活动队列管理器都会将数据发送到其他两个实例 (称为 “副本”)。每个副本写入自己的日志，确认数据，然后从复制的日志更新自己的队列数据。如果运行活动队列管理器的节点发生故障，那么队列管理器的其中一个副本实例将接管活动角色并具有要使用的当前数据。

优点：

高可用性：如果一个服务器失败，另一个服务器可以立即接管，从而减少了服务中断的时间。
简单性：云原生环境下, Native HA 使用了 IBM MQ 自身的功能，不需要额外的软件或硬件。
灵活性：你可以根据你的需求选择使用两个或更多的服务器来提供高可用性。

不足：

k8s运维,云原生环境

Minikube 云原生高可用搭建流程

1. 环境准备

    1. 安装docker desttop

    2. 安装minkube

    3. 安装helm

2. 启动3节点的k8s环境


minikube start -n 3 -p nativeha

3. Git clone [mq-helm](https://github.com/ibm-messaging/mq-helm/tree/main) 仓库

4. 在 samplesMinikube 目录下执行部署

      ./install.sh <namespace>

5. 测试，参考[这里](https://github.com/ibm-messaging/mq-helm/blob/main/samples/Minikube/README.md#testing)

可扩展性

IBM MQ 提供了一种称为集群的功能实现可扩展性。一个 MQ 集群是一组队列管理器，它们通过通道进行通信，并共享某些配置信息。这使得队列管理器可以动态地发现彼此，并自动路由消息。

工作机制和运行流程：

集群仲裁器（Cluster Repository）：集群中的一个或多个队列管理器被指定为集群仲裁器(比如图中的full_QM1和full_QM2)。它们存储集群的配置信息(完整存储库)，包括集群中的队列管理器、队列和通道。当新的队列管理器加入集群时，它会从集群仲裁器获取这些信息。
集群通道（Cluster Channels）：集群中的队列管理器通过集群通道进行通信。当一个队列管理器需要将消息发送到另一个队列管理器时，它会通过集群通道将消息发送出去。
集群队列（Cluster Queues）：集群队列是在集群中共享的队列(比如图中的队列Q1)。当一个队列管理器需要将消息发送到集群队列时，它不需要知道这个队列在哪个队列管理器上，它只需要将消息发送到集群队列，然后集群会自动将消息路由到正确的队列管理器。

以下是 IBM MQ 集群如何实现可扩展性机制：

动态路由：当一个应用程序发送消息到一个集群队列时，MQ 集群可以自动选择一个队列管理器来处理这个消息。这个选择是基于队列管理器的可用性和负载情况。这意味着你可以在不修改应用程序代码的情况下，通过添加更多的队列管理器来增加处理能力。
负载均衡：MQ 集群可以将消息负载均衡地分配到多个队列管理器。这是通过在集群中定义多个实例的同一个队列来实现的。当一个应用程序发送消息到这个队列时，MQ 集群将选择一个队列实例来存储这个消息。
高可用性：在一个 MQ 集群中，如果一个队列管理器失败，其他的队列管理器可以接管它的工作。这是通过在集群中定义多个实例的同一个队列，以及使用 MQ 集群的动态路由功能来实现的。
简化配置：在一个 MQ 集群中，队列管理器可以动态地发现彼此，以及彼此的队列和通道。这意味着你不需要在每个队列管理器上手动配置所有的队列和通道。当你添加一个新的队列管理器到集群时，它将自动被集群中的其他队列管理器发现。

Kafka Connect

可以利用 IBM 连接器实现 IBM MQ 与 Kafka 的集成。

Direct to queue (source)

此模式直接读取ibm-mq消息发送到kafka 相关topic上

Streaming queue copy (source)

此模式要求复制ibm-mq消息而不是直接消费。IBM MQ 9.3 使用流式队列将放入一个队列的消息由队列管理器复制到第二个队列，而不影响使用第一个队列的应用程序。

Direct to queue (sink)

此模式获取kafka 消息发送到ibm-mq队列中

参考文献

IBM MQ 简介
IBM MQ 点到点方案
IBM MQ docker部署运行
IBM MQ 高可用配置
IBM MQ 云原生高可用
IBM MQ k8s 高可用部署
使用 Websphere MQ 集群进行负载平衡
IBM MQ 实例集群
IBM MQ Kafka Connect 方案
一文读懂Kafka Connect核心概念
精通 WebSphere MQ(完整版).pdf