1. 安装前的准备工作与环境确认
1.1 为什么要选IBM MQ 7.5开发版
IBM MQ这玩意儿，很多刚接触消息中间件的人一听就头疼，总觉得是上世纪的大型机产物。但说实话，在金融、政企、制造业这些行业里，IBM MQ的存量部署量相当大，不少核心系统的数据交换还是靠它撑着。7.5这个版本虽然是2013年左右发布的，但胜在稳定、轻量、兼容性好，而且开发版License免费，用来学习、做原型验证、搭测试环境完全够用。
开发版和企业版的区别，说白了就是授权范围和用途不同。开发版不收费，但官方规定只能用于开发和测试，不能上生产。你学习MQ的基本概念、掌握队列管理器怎么建、通道怎么配、应用程序怎么连，这套流程用开发版跑一遍，跟企业版几乎没差别。等真到了生产环境，再按企业版的标准去部署，迁移成本也不高。
1.2 确认Linux发行版与系统版本
安装IBM MQ 7.5之前，我建议你先确认自己的Linux发行版。MQ 7.5官方支持Red Hat Enterprise Linux 5、6、7，以及SUSE Linux Enterprise Server 11等。但在实际测试中，CentOS 6、CentOS 7、Oracle Linux 7这些RHEL系的发行版都能正常装。如果你是Ubuntu、Debian这类Debian系的系统，会稍微麻烦一点——MQ 7.5官方只提供RPM包，没有DEB包，需要在Ubuntu上先装一个alien做格式转换，或者干脆用Docker跑一个CentOS容器。
我这次用的是CentOS 7.9，内核版本3.10，内存4G，磁盘40G，属于比较典型的“够用就行”的测试机配置。IBM MQ 7.5对硬件要求不高，1G内存、2G磁盘就能跑起来，但你要是同时跑队列管理器、Java应用、做性能压测，建议至少给2G内存。
操作系统确认命令我就不啰嗦了，cat /etc/redhat-release和uname -a，这两个命令足够你判断发行版和内核版本。装之前还要确认两件事：一是网络能不能通，因为后面安装依赖包时可能需要用yum；二是防火墙和SELinux的状态，这两个往往是MQ装完却连不上的罪魁祸首。
1.3 获取开发版安装包
IBM MQ 7.5的开发版安装包，在IBM官网的Downloads页面能找到。你可能会问，7.5这么老的版本，官网还提供下载吗？答案是提供的，IBM把MQ 7.5、8.0这些版本的开发者版下载链接保留得很好，只是入口藏得比较深。你在搜索框里输入“IBM MQ 7.5 Developer Trial”，一般能找到对应的下载页面。
下载下来你会得到一组RPM包，命名方式类似这样：
MQSeriesRuntime-7.5.0-0.x86_64.rpm MQSeriesServer-7.5.0-0.x86_64.rpm MQSeriesClient-7.5.0-0.x86_64.rpm MQSeriesSDK-7.5.0-0.x86_64.rpm MQSeriesSamples-7.5.0-0.x86_64.rpm MQSeriesMan-7.5.0-0.x86_64.rpm如果你只需要服务端，MQSeriesRuntime、MQSeriesServer、MQSeriesSDK、MQSeriesSamples这四个核心包是必须的。MQSeriesMan是帮助文档，不装也能跑。MQSeriesClient是客户端库，如果你在同一台机器上跑客户端连接测试，也建议装上。
注意：不同操作系统的RPM包架构后缀不一样，x86_64对应64位系统，i386对应32位系统。现在基本都是64位系统，直接选x86_64就行。下载时务必确认你的系统是RedHat系，否则后面rpm安装会报“wrong architecture”或者“is not designed for this platform”之类的错误。
2. 安装包的解压、依赖处理与正式安装
2.1 解压后的文件结构
下载好的安装包通常是一个.tar.gz压缩包，先解压到一个干净的目录。我习惯放在/opt/mqinstall下，方便统一管理：
mkdir -p /opt/mqinstall cd /opt/mqinstall tar -zxvf MQ_7.5_TRIAL_LNX_X86_64.tar.gz解压后，你会看到一个MQServer目录，里面才是真正的RPM包数组。顺便说一句，IBM的这个tar包有时会在根目录放一个README或License文件，建议先扫一眼，主要是确认版本号和授权注意事项。
2.2 RPM安装顺序与依赖处理
这里有一个很多人踩过的坑：RPM包不能一次性全部rpm -ivh *.rpm盲目安装，因为包之间存在依赖关系。顺序建议是：
rpm -ivh MQSeriesRuntime-7.5.0-0.x86_64.rpm rpm -ivh MQSeriesServer-7.5.0-0.x86_64.rpm rpm -ivh MQSeriesSDK-7.5.0-0.x86_64.rpm rpm -ivh MQSeriesSamples-7.5.0-0.x86_64.rpm rpm -ivh MQSeriesMan-7.5.0-0.x86_64.rpm为什么是这个顺序？因为MQSeriesServer依赖MQSeriesRuntime提供的基础库和运行环境，而MQSeriesSDK又依赖MQSeriesServer中的头文件和服务端组件。先装Runtime，再装Server，这是从底层到上层的依赖关系。你要是乱序安装，大概率会看到类似“libmqm.so is needed by MQSeriesServer”这样的依赖报错。
依赖库方面，CentOS 7最小化安装的情况下，一般需要先装ksh和bc。MQ的很多管理脚本是用ksh写的，缺了ksh可能导致后续的crtmqm、strmqm脚本执行异常。bc则是做运算法则校验用的，不装问题不大，但建议一起装了：
yum install -y ksh bc另外，IBM MQ 7.5在安装时会自动创建名为mqm的系统用户和用户组，不需要你手动创建。安装完成后，/opt/mqm目录就是MQ的安装目录，所有二进制文件、库文件、许可文件都在里面。
2.3 安装完成的验证
装完之后，验证一下安装是否完整。我用三个命令来做基本检查：
ls -ld /opt/mqm /opt/mqm/bin/dspmqver /opt/mqm/bin/dspmqdspmqver会输出IBM MQ的版本信息，比如Version: 7.5.0.0。dspmq是显示队列管理器状态的命令，如果当前还没有创建任何队列管理器，它会输出类似AMQ7064: No queue manager has been created的信息，属于正常现象。
到这里，安装本身就算完成了。但别急着建队列管理器，建议先做一步环境变量配置。MQ装完后，/opt/mqm/bin下有一堆命令，但默认没有加入当前用户的PATH。你可以把相关环境变量写进~/.bash_profile：
export MQ_INSTALLATION_PATH=/opt/mqm export PATH=$PATH:/opt/mqm/bin:/opt/mqm/samp/bin export MANPATH=$MANPATH:/opt/mqm/man注意：用
mqm用户登录时，这些环境变量是必须的。你当然也可以用绝对路径/opt/mqm/bin/xxx执行命令，但那样太累，而且后续用runmqsc交互式敲命令时，没有环境变量支持会各种别扭。
3. 创建队列管理器：从命名到初始化参数
3.1 队列管理器的概念与命名规则
在动手创建之前，先搞清楚一个核心概念：IBM MQ里最顶层的管理单元是“队列管理器（Queue Manager）”。你可以把它理解成一个独立的“消息处理服务器实例”——它管着自己下面的一堆队列、通道、监听器，不同队列管理器之间的消息是物理隔离的，互不干扰。
命名规则上，队列管理器的名字最多48个字符，但在Linux上建议控制在12个字符以内，方便用runmqsc交互时频繁输入。名字只能包含字母、数字、点号、下划线，而且不能以数字开头。我测试时常用QMGR1、TESTQM这样的名字，简单明了。
3.2 用crtmqm创建队列管理器
创建队列管理器直接使用crtmqm命令：
crtmqm -q TESTQM这里的-q参数表示启用队列管理器上的队列控制功能，中文环境一般建议加这个参数，它能保证队列文件的正确初始化。如果你不加-q，在某些语言环境下，可能会碰到队列文件编码不一致导致的怪异问题。
创建成功后，系统会输出类似IBM MQ queue manager created.字样。此时你可以用dspmq查看状态，正常会显示QMNAME(TESTQM) STATUS(Ended normally)——注意，这里的状态是“Ended normally”，意思是队列管理器已经创建但还没启动，不要误以为出错了。
3.3 启动队列管理器
启动队列管理器用strmqm命令：
strmqm TESTQM第一次启动会比较慢，因为要初始化内部系统队列、恢复日志等。启动成功后，输出会显示IBM MQ queue manager 'TESTQM' started.。
到这里，队列管理器已经在运行了，但你还没有任何队列可以收发消息。接下来需要进入runmqsc交互式环境，创建队列、通道、监听器这些资源。
runmqsc是IBM MQ的管理命令解释器，类似于数据库的sqlplus。用法很简单：
runmqsc TESTQM进入后会出现>提示符。在这个交互式环境下，你可以执行DEFINE、DISPLAY、ALTER、DELETE、START、STOP等管理命令。
注意：
runmqsc中的命令是不区分大小写的，但资源名字要注意大小写一致性。IBM MQ在Linux上的命名是大小写敏感的，Queue1和queue1是两个不同的队列。为了避免混乱，建议统一用大写字母定义资源名。
4. 队列与通道配置：让消息真正流动起来
4.1 创建本地队列
队列是消息的存储容器，本地队列就是真正物理存储消息的队列。在runmqsc里执行：
DEFINE QLOCAL(TEST.QUEUE) DESCR('Test local queue') MAXDEPTH(5000) DEFPSIST(YES)简单解释一下这些参数的意义：
QLOCAL表示这是一个本地队列，消息真正存储在这个队列管理器的本地磁盘上。DESCR是对队列的描述信息，方便别人看队列是干嘛用的。MAXDEPTH是队列的最大深度，就是最多能堆积多少条消息。默认是5000，测试环境够用。DEFPSIST(YES)表示消息默认是持久化的。持久化消息会写入日志，队列管理器重启后消息不丢；非持久化消息存在内存中，性能更快但重启会丢。如果做的是日志、通知类数据，建议用持久化。
创建完队列后，可以用DISPLAY QUEUE(TEST.QUEUE)来查看队列的详细信息，确认创建成功。
4.2 创建服务器连接通道
通道是客户端应用连接队列管理器的大门。IBM MQ里有很多种通道类型，做开发测试时最常用的是SVRCONN（服务端连接通道）。应用程序通过这个通道连接上队列管理器，然后才能读写队列。
DEFINE CHANNEL(TEST.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE这条命令定义了一个名为TEST.SVRCONN的TCP服务端连接通道。REPLACE是“如果同名通道已存在就替换”的意思，主要用于脚本幂等执行。
4.3 创建监听器并绑定端口
有了通道还不够，队列管理器必须有一个监听器在指定的TCP端口上“听候指令”，客户端应用的连接请求才能到达。创建监听器：
DEFINE LISTENER(LST.TEST) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR) START LISTENER(LST.TEST)这里有两个关键点：
PORT(1414)：IBM MQ的默认端口就是1414。如果你机器上的1414被占了，可以换个端口，比如1415。但客户端连接时，端口必须和这里配置的一致。CONTROL(QMGR)：表示监听器由队列管理器启动时自动启动，队列管理器停止时也自动停止。这个参数很省心，不用每次重启队列管理器后手动去启动监听器。
启动监听器后，可以用DISPLAY LISTENER(LST.TEST)查看监听器状态。正常情况下状态是RUNNING。
4.4 授权与权限设置
很多人在本地测试时，发现应用连不上队列管理器，或者连上了但打不开队列，问题往往出在权限配置上。IBM MQ的权限体系比较复杂，但开发测试环境你只需要掌握一个命令：setmqaut。
比如，要给mqm用户（或者某个应用用户）授予对TEST.QUEUE队列的全部权限：
setmqaut -m TESTQM -t qmgr -p mqm +connect +inq setmqaut -m TESTQM -t queue -n TEST.QUEUE -p mqm +put +get +browse +inq第一行是给mqm用户授予连接队列管理器的权限，第二行是授予对队列的写入、读取、浏览和查询权限。
如果你希望所有本地用户都能访问，可以使用-g mqm指定用户组，或者直接用-p参数指定具体用户。实际操作中，我建议明确指定用户，不要图省事直接给-g mqm，因为mqm组用户相当于MQ的超级管理员，生产环境这么搞风险很大。
重要提示：每次修改完权限后，不需要重启队列管理器或队列，权限即时生效。这一点我实测过，比改操作系统文件权限要人性化很多。
4.5 保存并退出runmqsc
所有配置完成之后，用END命令退出runmqsc。如果你希望修改自动保存，直接输END即可；如果输QUIT，效果其实一样，都会保存并退出。除非你在运行过程中显式地使用了-z之类的回滚选项，否则配置都会写入队列管理器的配置文件。
退出后，可以用runmqsc TESTQM < testscript.mqsc的方式把上述所有命令保存成脚本，这样以后重建环境时，一行命令就能搞定。这也是我强烈推荐的做法——把整个初始化过程固化成脚本，比每次手动敲命令强太多。
5. 应用接入：Java与C客户端的连接测试
5.1 使用Java应用测试连接
IBM MQ 7.5自带一套JMS和Java库，位于/opt/mqm/java/lib目录。测试前，先把这些库加入CLASSPATH：
export CLASSPATH=/opt/mqm/java/lib/com.ibm.mq.jar:/opt/mqm/java/lib/com.ibm.mqjms.jar:/opt/mqm/java/lib/jms.jar:/opt/mqm/java/lib/connector.jar:/opt/mqm/java/lib/com.ibm.mq.jmqi.jar:$CLASSPATH然后写一个简单的Java程序，目标是往TEST.QUEUE里发一条消息再读回来。这里的关键点有：
MQEnvironment.hostname设置为服务器地址，本机测试就用localhost。MQEnvironment.port要填监听器绑定的端口，即1414。MQEnvironment.channel填通道名TEST.SVRCONN。- 连接工厂创建之后，必须
setTransportType(JCATransport.JMSC)，表示走客户端模式连接。默认的BINDINGS模式是进程内绑定，只适合应用和队列管理器在同一台机器、同一个用户环境下的场景。
如果你用的是纯MQ基础类（非JMS），还有一套更直接的写法，但代码量会多不少。开发测试阶段，我建议直接用JMS接口，代码最简洁，也最容易排查问题。
5.2 C/SDK客户端连接
IBM MQ同时提供C语言的客户端接入方式。在Linux环境里，编译时需要链接libmqm.so和libmqic.so两个库。一个最小化的C客户端发送程序，核心步骤也就是：MQCONN连接队列管理器、MQOPEN打开队列、MQPUT发送消息、MQDISC断开连接。
编译命令大致如下：
gcc -o mqput mqput.c -I/opt/mqm/inc -L/opt/mqm/lib -lmqm -lmqic如果你只想快速验证：发送方可以用IBM MQ自带的示例程序。在/opt/mqm/samp/bin目录下，有amqsputc和amqsgetc两个命令行工具，分别用于发送和获取消息，用法：
/opt/mqm/samp/bin/amqsputc TEST.QUEUE TESTQM输入内容后按两下Ctrl+D结束输入，消息就发送到了TEST.QUEUE。再用：
/opt/mqm/samp/bin/amqsgetc TEST.QUEUE TESTQM就会把消息读出来打印到标准输出。用这种方式做端到端验证，远比写一个复杂的Java程序高效。
5.3 验证消息的持久化与重复消费
实际开发中总会遇到“消息队列重复消费”的问题。这个和MQ本身的关系在于：IBM MQ支持“刚好一次”传递，前提是你正确使用了SYNCPOINT（同步点）机制。
用JMS做事务型会话时，消息的接收和业务处理处在同一个事务中。当session.commit()成功提交后，MQ才会真正把消息标记为“已消费”。如果在commit()之前应用崩溃了，MQ会认为这条消息还没被消费，等应用下一次重连时，消息会被重新投递给消费者——这就是“重复消费”现象产生的根本原因。
所以，在使用IBM MQ时，你的消费者应用必须做到“幂等性”——也就是同一条消息处理两次和一次，最终结果是一样的。这个在上游消息、支付回调对接时尤其重要。MQ本身不会主动去重，它只保证“至少一次”或“刚好一次”的投递语义，去重逻辑必须由业务代码自己实现。
处理重复消费的常见方案：给每条消息加一个唯一的业务ID，业务侧用一个去重表或Redis做记录，消息处理前先查一下这个ID是否处理过。防重逻辑放在消息消费侧，这是行业里的标准做法。
6. 常见问题与排查技巧实录
6.1 客户端连接失败：AMQ4036
实际测试中，我最常遇到的错误就是AMQ4036，含义是“对队列管理器或队列没有授权”。这个错误几乎可以断定问题出在setmqaut没有配置好，或者通道配置的MCAUSER设置了受限用户。
排查步骤：
- 用
DISPLAY CHANNEL(TEST.SVRCONN)查看通道的MCAUSER字段。如果MCAUSER指向了一个不存在或者权限受限的用户（比如nobody），客户端连接必挂。 - 检查是否执行了
setmqaut授权命令，特别是+connect权限。 - 如果还是不不行，可以临时把通道的
MCAUSER置空（即不限制），再测试。注意生产环境不能这么干，否则任何人连上通道就能访问队列管理器。
在开发测试环境，如果懒得做详细授权，最省事的方案是把TEST.SVRCONN的MCAUSER设置为mqm：
ALTER CHANNEL(TEST.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('mqm')这样所有通过该通道进来的连接，都拥有mqm用户权限，开发调试非常方便。但记住，仅限测试环境。
6.2 端口不可达：检查防火墙与SELinux
如果你发现应用连接报超时，或者telnet 192.168.x.x 1414一直卡住，问题大概率出在Linux防火墙或SELinux上。
CentOS 7的firewalld默认会把外部端口的访问挡掉。放行1414端口：
firewall-cmd --zone=public --add-port=1414/tcp --permanent firewall-cmd --reload如果不想麻烦，测试环境直接停掉防火墙也可以：
systemctl stop firewalld systemctl disable firewalld另一个容易忽视的是SELinux。很多人装完MQ后连接失败，查了半天才发现是SELinux拦截了进程的网络访问。临时关闭SELinux：
setenforce 0永久关闭则编辑/etc/selinux/config，把SELINUX=enforcing改成SELINUX=disabled，然后重启系统。注意，SELinux从enforcing到disabled，必须重启才能完全生效，只改文件不重启是不行的。
6.3 队列管理器无法启动
用strmqm TESTQM启动时，如果卡住很久或者直接报错，一种常见原因是MQ的日志目录权限不对。检查/var/mqm目录的所有者是否为mqm用户：
ls -ld /var/mqm chown -R mqm:mqm /var/mqm还有一种情况是系统临时目录空间不足，MQ启动时需要创建共享内存和临时文件。用df -h /tmp检查一下，如果使用率接近100%，清理临时文件后重启MQ。
6.4 runmqsc输出乱码或命令不可识别
如果你用的是中文语言环境的Linux，某些MQ 7.5版本的runmqsc交互接口可能出现乱码，或者输入命令后报错“Invalid command”。这时候最有效的两个方法：
- 在连接时强制使用英文语言环境：
export LANG=en_US.UTF-8，然后再runmqsc TESTQM。 - 把整个会话脚本通过
<重定向执行，比如runmqsc TESTQM < /opt/mqinstall/test.mqsc，这样脚本内容就是纯ASCII，不存在字符集混入问题。
6.5 日志与错误定位的常用命令
最后再讲一下排查问题的“三板斧”。IBM MQ的错误日志主要放在：
/var/mqm/qmgrs/TESTQM/errors/AMQERR01.LOG /var/mqm/errors/AMQERR01.LOG这两个文件平时不引人注意，但一旦出问题，里面的信息量非常大。比如客户端连不上时，服务端日志里会详细记录“通道校验失败”“连接被拒绝”“权限不足”等具体原因，比客户端报错信息有用得多。
另外两个实用命令：
dspmq -o status # 查看所有队列管理器及运行状态 DISPLAY CHSTATUS(TEST.SVRCONN) # 在runmqsc里查看通道当前状态和连接数DISPLAY CHSTATUS能看到当前有多少个客户端连接占有这个通道，特别适合排查“连接数打满”的问题。MQ 7.5默认通道最大连接数是100，如果你测试时并发连接数超过100，需要调整MAXINST和MAXINSTC参数，但开发环境一般不会碰到。
7. 运维必要知识：日志管理、队列监控与备份建议
7.1 日志文件的使用情况
IBM MQ 7.5默认使用循环日志（circular logging），日志文件存放在/var/mqm/log/TESTQM目录下。循环日志的好处是自动覆盖旧日志，不会把磁盘写满；坏处是如果你需要做灾难恢复，它只能恢复到问题发生前最近的一小段时间。
开发测试环境用循环日志就够了，完全不需要改成线性日志。线性日志会持续追加，磁盘空间不够就会导致队列管理器拒绝启动，这在生产环境是常态，但测试环境没必要给自己找事。
7.2 队列深度的日常监控
测试环境你可能不在意队列深度，但一旦应用写多读少，消息就会在TEST.QUEUE里堆积，时间久了可能触发MAXDEPTH上限。到那时，MQPUT会直接报MQRC_Q_FULL（原因码2053），如果应用没有做异常处理，很容易引发连环故障。
日常监控队列深度，我用一个很简单的命令：
echo "DISPLAY QSTATUS(TEST.QUEUE) CURDEPTH" | runmqsc TESTQM实时看队列当前深度，是运维MQ最基本的操作。生产环境一般会通过MQ的dmpmqcfg定期导出配置、用QMgr Status页面或者第三方监控工具做告警，但原理都是从队列深度、通道状态、日志错误三个维度出发。
7.3 配置备份与快速恢复
最后强烈建议大家把配置过程“脚本化”。我在/opt/mqinstall目录下维护了一个init_mq.mqsc，内容就是上面讲到的所有DEFINE命令：
DEFINE QLOCAL(TEST.QUEUE) MAXDEPTH(5000) DEFPSIST(YES) REPLACE DEFINE CHANNEL(TEST.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE DEFINE LISTENER(LST.TEST) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR) REPLACE START LISTENER(LST.TEST)以后换机器、重装系统时，只需要两条命令就能恢复整个环境：
crtmqm -q TESTQM strmqm TESTQM runmqsc TESTQM < /opt/mqinstall/init_mq.mqsc再配合dmpmqcfg -m TESTQM -a导出全部配置（包含权限），整个环境的“灾备恢复”就算完成了一大半。我个人的体会是，消息中间件的安装配置本身只是第一步，真正考验人的是后续的监控、备份、权限管理。把这几件事在测试环境里提前演练熟了，到了生产环境才不会手忙脚乱。
如果你后续计划从Java、Spring Boot这些现代框架接入MQ，7.5本身对JMS的支持已经很成熟，连接池、事务、消息确认这些机制都能用，不会因为版本老而影响开发体验。可以先在7.5上把概念跑通，等需要更优秀的吞吐性能和更简便的运维管理时，再平滑升级到9.x版本也不迟。
