简介IBM MQ原WebSphere MQV7.5.0.2在Windows平台上的试用版安装包面向需要学习和使用企业级消息队列的开发者、运维人员可帮助解决分布式系统间异步通信、可靠传输与系统解耦等问题。压缩包共含1001个文件主要格式有gif、htm、txt、css等其中gif与htm多为界面演示和帮助文档txt与ini等为配置信息exe、msi、cab为安装程序及组件pdf、txt等提供说明与参考整体约357MB。已有369人浏览学习。除完整的安装向导和服务器、客户端组件外包内资料还系统覆盖了队列管理器、通道配置、安全机制、JMS接口以及点对点、发布/订阅等核心概念适合从零开始安装、配置并开展实验也可作为理解IBM MQ架构与API用法的实用参考。对于刚接触消息队列的用户txt配置示例与htm说明页能快速帮助理解参数含义对于需要搭建测试环境的人员组件包也便于部署验证。1. 一个文件名里藏着多少信息做中间件这行久了拿到一个安装包第一件事不是双击运行而是先拆文件名。WS_MQ_V7.5.0.2_TRIAL_FOR_WINDOWS_ML.rar这串字符基本能把这款软件的家底交代清楚。WS_MQ 是 IBM WebSphere MQ 的缩写也就是后来改名为 IBM MQ 的那款消息中间件。V7.5.0.2 表示大版本是 7.5修复包级别到了 0.2也就是 7.5.0.2 版本。TRIAL 说明是试用版通常会附带时间限制或功能限制。FOR_WINDOWS 明确这是 Windows 平台的安装包。最后的 ML 不是 Machine Learning而是 Multi-Language多语言版本意味着安装过程中可以切换中文、英文、日文、韩文等多种界面语言。很多人看到试用版三个字就摇头觉得不如正式版踏实。但在实际企业环境里试用版的价值恰恰被低估了。我见过不止一个项目组在采购流程还没走完的时候用试用版提前把环境搭起来做 POC 验证等正式 license 下来直接无缝切换。7.5 这个版本虽然发布时间较早但在存量系统里仍然有大量部署尤其是金融、物流、制造业的核心链路里7.5 的队列管理器还在稳定运行。如果你正在维护一套老系统或者需要在一个临时环境里验证 MQ 的收发消息逻辑又或者想学习消息队列的底层机制这个安装包都能派上用场。接下来我会从安装规划、部署步骤、配置验证到踩坑排查完整走一遍基于 Windows 的 WS_MQ 7.5 试用版落地流程。这不是什么高深操作但里面的细节真不少照着做能省很多时间。2. WS_MQ 7.5 的定位为什么老版本至今仍被需要2.1 消息中间件里的老大哥WebSphere MQ 的历史可以追溯到 1993 年的 MQSeries1990 年代末被 IBM 整合进 WebSphere 产品线。7.5 版本发布于 2012 年是 MQ 历史上一个承上启下的版本它完整支持了 IPv6、TLS 1.2需要修复包配合、多实例队列管理器以及更细粒度的安全控制。虽然后面 8.0、9.0、9.1、9.2、9.3 陆续推出但很多企业的核心系统从上线起就跑在 7.5 上运维团队对它的脾气摸得透透的不到万不得已不会主动动这块压舱石。从技术指标上看7.5 的单队列管理器可支撑数万并发连接消息持久化、事务回滚、集群负载均衡这些企业级能力都已经是成熟状态。即使放在今天它的性能表现也完全够用。2.2 试用版和正式版到底差在哪试用版不是阉割版这一点很多人有误解。WS_MQ 的试用授权Trial License允许你在 90 天内免费使用完整功能包括队列管理器、MQ Explorer 图形工具、所有的 API 接口。区别只在于试用授权有时间限制到期后队列管理器仍然可以启动但会报授权过期需要卸载重装或者购买正式 license 后重新授权。试用版安装包不会自动下载修复包或安全补丁后续升级需要手动处理。正式版可以获得 IBM 官方技术支持试用版只能依靠社区和文档。所以如果你是为了学习或者做技术验证试用的功能完全没有缩水这一点可以放心。2.3 部署前的环境评估与版本选择在 Windows 上装 MQ 之前先检查三件事。第一操作系统兼容性。7.5 官方支持 Windows Server 2008 R2、2012、2012 R2以及 Windows 7 专业版/企业版。在更新的 Windows Server 2016、2019、2022 上7.5 也能跑但需要安装相应的 MSI 修复包来规避兼容性告警。如果你手头是 Windows 11 或者 10 专业版装起来问题不大但在生产环境不建议这么干。第二磁盘和内存。MQ 本身安装包不到 1GB但运行时需要日志空间和队列数据空间。建议预留至少 5GB 磁盘空间内存方面队列管理器和客户端进程加起来大概占用 300MB 到 500MB如果做压力测试按每秒几千条消息的规模估算至少准备 4GB 内存。第三端口规划。默认的队列管理器监听端口是 1414客户端连接通道使用 TCP。如果你的机器上已经有其他服务占用了这个端口安装前就要改掉。注意7.5.0.2 属于比较早期的修复级别。如果你要对接的是新版本 MQ 客户端比如 9.x 的 MQI 客户端建议在安装 7.5 基础版之后补装 7.5.0.8 以上的修复包否则客户端连接时可能出现协议不兼容的问题。3. Windows 环境下的完整安装链路3.1 解压与安装前的环境准备拿到.rar文件后先解压。这里有个细节不要用 Windows 自带的全部解压缩因为中文字符路径可能导致解压后的安装程序无法启动。建议用 7-Zip 或 WinRAR解压路径也尽量选英文目录比如D:\MQ_Install\。解压后你会看到类似下面的内容image目录存放安装镜像文件Windows目录包含安装脚本和配置模板README或Install.doc官方安装说明.rsp文件响应文件用于无人值守安装如果你在解压后的目录里找不到传统的setup.exe不要慌。MQ 7.5 的 Windows 安装入口是Setup.bat或者通过 MSI 包触发。找到image\Windows目录里面会有Setup.exe和一堆.msi文件双击Setup.exe即可进入安装向导。3.2 图形化安装步骤详解整个图形化安装过程分六个阶段每一个阶段都有需要注意的选项。第一步接受许可协议。这是试用版的重点必须勾选我接受许可证条款否则下一步按钮是灰色的。第二步选择安装类型。有典型安装、自定义安装和只安装客户端三个选项。这里要按用途区分如果你要部署完整的队列管理器选典型安装它会装上服务器组件、MQ Explorer 和开发工具包。如果你只是需要连到远程队列管理器做消息收发选只安装客户端就够了体积小、启动快。如果你要折腾集群、多实例这些高级功能选自定义安装把MQ 高级组件勾上。从实用角度出发建议选择自定义安装即使暂时用不到后面省得重新装。第三步设置安装目录和权限。MQ 推荐装在非系统盘比如D:\Program Files\IBM\WebSphere MQ。这一步还要指定 mqm 用户组。默认情况下安装程序会自动创建名为mqm的本地用户组凡是加入这个组的用户都有权限管理队列管理器。如果你是在域环境里建议额外建一个专用的域账号加进 mqm 组后面做集群或者远程管理更方便。第四步选择功能组件。这部分有十几个子选项最核心的是服务器运行时和客户端运行时。如果空间足够建议全部勾选包括 JMS 支持和 .NET 支持因为 7.5 的 JMS 客户端和 .NET 客户端在开发中非常常用。第五步预检和安装。安装程序会检查系统依赖比如是否安装了 Microsoft Visual C Redistributable。如果缺 VC 运行库安装会直接中断。遇到这种情况先去微软官网下载对应的 VC 2010 x64/x86 运行库装好后再重试。第六步安装完成后的授权配置。安装完成后打开命令提示符切换到 MQ 安装目录的bin文件夹执行setmqaut -m QM.NAME -t qmgr -p mqm all这是给 mqm 组授予队列管理器的全部权限。新装的 MQ 默认权限只允许管理员用户操作不加这条授权的话后续用非管理员用户创建队列管理器会报权限不足。3.3 无人值守安装一条命令搞定部署如果你需要批量部署多台 Windows 服务器图形化安装就太慢了。MQ 提供了响应文件安装方式一步到位。在解压目录里找到.rsp文件模板比如InstallSamples.rsp复制一份之后按实际需求修改# 安装类型1典型2自定义 INSTALL_TYPE2 # MQ 安装路径 MQ_INSTALL_ROOTD:\Program Files\IBM\WebSphere MQ # 是否创建 mqm 组1是 MQ_CREATE_GROUP1 # 安装组件多个组件用逗号分隔 MQ_COMPONENTSServer,Client,Explorer,JMS保存后以管理员身份打开命令提示符进入安装目录执行Setup.exe /s /v/qn TRANSFORMSSetupTransform.mst或者直接调用 MSI 安装包msiexec /i MQ_V7.5.0.2_Windows.msi /qb TRANSFORMSSetupTransform.mst实测下来响应文件安装整个过程大约 10 到 15 分钟比图形化快一半以上。而且响应文件可以反复调整适合做运维标准化。4. 装完之后必须做的事队列管理器与队列的配置安装完成只是第一步接下来要创建队列管理器、配置队列和通道这才能让 MQ 真正跑起来。4.1 创建队列管理器在命令提示符里输入crtmqm QM_APP这个命令会在默认位置创建名为QM_APP的队列管理器并生成对应的目录结构和日志文件。如果需要在特定路径创建数据目录可以加参数crtmqm -ld D:\MQData\QM_APP\log -md D:\MQData\QM_APP\data QM_APP-ld指定日志目录-md指定消息数据目录。生产环境建议把日志和数据分开放在不同的物理磁盘上减少 I/O 竞争。创建完队列管理器后启动它strmqm QM_APP看到WebSphere MQ queue manager QM_APP starting和WebSphere MQ queue manager QM_APP started的输出说明启动成功。4.2 创建队列和通道队列管理器启动后用runmqsc命令行工具创建队列。这个工具是所有 MQ 管理员的重度依赖用法不难但命令格式必须记牢。进入工具界面runmqsc QM_APP在runmqsc交互环境里依次输入以下命令DEFINE QLOCAL(DEV.QUEUE) MAXDEPTH(5000) DEFPSIST(YES) DEFINE CHANNEL(DEV.CHANNEL) CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER(mqm) ALTER QMGR CHLAUTH(DISABLED) ALTER QMGR CONNAUTH( )第一行创建本地队列DEV.QUEUE最大深度 5000 条消息默认持久化。第二行创建服务端连接通道DEV.CHANNEL允许 mqm 用户通过 TCP 连接。第三行和第四行是为了开发环境方便调试把通道认证和连接认证临时关闭。这里必须提醒一句CHLAUTH(DISABLED)和CONNAUTH( )在生产环境千万不能这么配。7.5 默认开启通道认证如果没做用户映射客户端连接会被拒绝。开发环境图省事可以关掉生产环境要保留认证并配置合理的用户和权限。我当时在这个坑里栽过一次测试环境关闭了认证拿到生产环境做同样操作结果安全审计直接亮红灯。退出runmqscEND4.3 用 MQ Explorer 做可视化验证命令行的方式虽然高效但新手容易晕。MQ Explorer 是 MQ 自带的图形化管理工具在开始菜单里找到WebSphere MQ Explorer打开在左侧导航栏右键队列管理器添加刚才创建的QM_APP。添加到 Explorer 后你能直观看到队列深度、通道状态、当前连接数甚至可以直接往队列里放一条消息测试。对一个刚接触 MQ 的开发者来说这个工具比命令行友好得多。我的习惯是命令行负责脚本化和批量操作Explorer 负责日常监控和临时排查两者配合使用效率最高。4.4 一个最简发送接收验证为了确认环境真的通了写一个最简单的测试。MQ 自带了一个命令行测试工具amqsput和amqsget分别用于往队列放消息和取消息。先开一个命令窗口amqsput DEV.QUEUE QM_APP输入一行消息比如hello mq按回车消息就放进去了。再按一次 CtrlZ 结束输入。再开第二个窗口amqsget DEV.QUEUE QM_APP如果能看到刚才输入的hello mq说明整条链路——队列管理器、队列、消息持久化——已经全部正常。5. 试用期内的常见坑与排查实例装 MQ 这么多年我遇到过不少看起来莫名其妙的问题这里挑几个最常见的按现象—原因—处理列出。5.1 队列管理器启动失败卡在 Starting 状态现象执行strmqm QM_APP后输出显示starting但十几秒后报错AMQ6118: WebSphere MQ queue manager could not be started or restarted。原因排查链路第一步查看错误日志。MQ 的错误日志在安装目录的errors文件夹比如D:\Program Files\IBM\WebSphere MQ\errors\AMQERR01.LOG。打开后搜索AMQ开头的错误码最常见的错误码是AMQ5540表明队列管理器权限配置有误。第二步检查 mqm 组。如果安装 MQ 时用的是管理员账号但当前执行strmqm的用户不在 mqm 组里就会启动失败。处理方法是把当前用户加入 mqm 组或者直接用安装时创建的管理员账号执行。第三步检查端口占用。虽然端口冲突通常不影响队列管理器启动但通道监听无法绑定端口时启动流程会卡住。用netstat -ano | findstr 1414查看端口是否被占用如果被占在runmqsc里修改监听端口。5.2 客户端连接报 2538 错误现象应用连接队列管理器时抛MQRC_UNKNOWN_CHANNEL_NAME(2538)明明通道名写对了。原因这个错误十有八九是通道类型不匹配。服务端连接通道SVRCONN只允许CLNTCONN类型的客户端通道连接如果服务端建的是发送通道SDR或接收通道RCVR客户端是连不上的。用DISPLAY CHANNEL(DEV.CHANNEL)查看通道类型确认是SVRCONN即可。另外一个隐藏原因7.5 的通道名称最大长度是 20 个字符。超过 20 个字符的通道名会被截断客户端就找不到实际存在的通道。命名的时候别图省事但也不要起太长。5.3 消息堆积不消费现象队列深度一直涨应用不消费或者消费极慢。排查思路先去 MQ Explorer 看队列的GET权限确认消费应用用户是否有读取权限。用到dspmqaut -m QM_APP -t q -n DEV.QUEUE -p appuser查看具体权限。如果权限正常那就是应用层面的问题。用amqsbcst或者查看应用的日志确认消费客户端是否建立了正确的会话。MQ 的消费方式有轮询和回调两种7.5 的 .NET 客户端里有两种监听模式MessageConsumer和MessageListener前者需要手动循环取消息后者是事件驱动。如果代码里用的是MessageConsumer.Receive(0)表示永久等待但循环里没有正确提交事务也会导致消息一直锁在队列里不可见表面上看起来就是不消费。5.4 中文乱码问题7.5 的 ML 多语言版自带了中文字符集支持但在 Windows 上处理中文消息时经常出现乱码。原因通常是 MQ 字符集CCSID和操作系统的代码页不一致。Windows 中文版默认字符集是 GBKCCSID 1381 或者 936而 MQ 默认使用 UTF-8CCSID 1208。当 JMS 应用发送中文文本消息时如果连接的字符串里没有显式指定字符集MQ 会按照队列管理器的默认 CCSID 编码接收端解码时就会变成乱码。解决办法有两个在客户端连接字符串里显式指定CCSID1208双方统一用 UTF-8。在队列定义上设置CCSID(1208)但这需要生产环境的队列由开发团队统一规划不能随便动。我个人的处理方式是开发阶段就在代码里固定使用 UTF-8 编码发送和接收所有环境一致。虽然系统默认字符集可能不同但应用层的编码统一了乱码问题就彻底消失了。6. 从试用走向生产版本升级与迁移建议试用版到期后如果你的系统已经完成了验证要正式上线可以考虑两条路购买正式 license 继续使用 7.5或者迁移到更高版本。我的建议是新项目尽量用新版本老项目能不动就不动。6.1 正式授权与 7.5 的扩展支持IBM 在 2018 年之后把 WebSphere MQ 改名为 IBM MQ6.0 和 7.0 已停止服务7.1、7.5 也进入了扩展支持阶段。所谓扩展支持就是只针对安全补丁和特定问题修复不再做功能性更新。如果你所在的行业有合规要求建议尽早规划升级。6.2 升级到 IBM MQ 9.x 的迁移路径从 7.5 升级到 9.x 需要做几件事第一步备份。在升级前用dmpmqcfg -m QM_APP backup.mqsc导出对象定义再用saveqmgr备份队列管理器配置。数据文件用文件系统备份的方式拷贝一份到独立磁盘。第二步选择升级方式。9.x 支持原地升级和全新部署两种方式。原地升级很简单直接运行 9.x 的安装程序选择升级现有安装安装程序会自动检测到之前 7.5 的队列管理器数据目录升级过程中会保存配置并迁移日志。第三步验证客户端兼容性。9.x 的协议默认兼容 7.5 的老客户端但如果你的客户端是 7.5 之前的版本比如 7.1 或 6.0建议同步升级客户端因为老客户端在协议协商时可能触发 COMPAT 模式性能会受影响。6.3 我的一些个人体会用了一段时间 7.5 之后最大的感受是 MQ 的核心机制这么多年几乎没有变过——队列、通道、队列管理器三大要素以及消息持久化、事务处理、集群负载均衡这些概念在 9.x 里依然适用。所以哪怕你未来正式环境用的不是 7.5通过这个试用版把 MQ 的工作机制吃透后面的学习曲线也会平缓很多。有个小建议装完试用版后除了跑通基础的 put/get一定要花时间把以下场景也验证一遍断网重启把 Windows 的网络断开看看队列管理器在监听端口不可达时是否仍然能正常处理本地消息。队列写满把MAXDEPTH故意设小往队列里打满消息观察生产者报什么错消费者恢复后消息是否自动继续流动。通道断线重连在客户端连上之后手动停掉服务端通道等待几秒再启动观察客户端是否能自动重连。这几个场景模拟了现实生产里的典型故障提前踩一遍坑后面真正上线的时候心里就有底了。关于 7.5.0.2 这个版本最后再补一句。如果你是刚接触 MQ完全没必要执着于最新版本把 7.5 安装包里的README仔细读一遍比在论坛上搜各种零散资料高效得多。官方文档里不光有安装步骤还包含了 7.5 在 Windows 上已知问题的列表和对应修复包号这些信息才是安装调试阶段最能救命的东西。本文还有配套的精品资源点击获取
Windows平台IBM MQ 7.5试用版安装与配置指南
简介IBM MQ原WebSphere MQV7.5.0.2在Windows平台上的试用版安装包面向需要学习和使用企业级消息队列的开发者、运维人员可帮助解决分布式系统间异步通信、可靠传输与系统解耦等问题。压缩包共含1001个文件主要格式有gif、htm、txt、css等其中gif与htm多为界面演示和帮助文档txt与ini等为配置信息exe、msi、cab为安装程序及组件pdf、txt等提供说明与参考整体约357MB。已有369人浏览学习。除完整的安装向导和服务器、客户端组件外包内资料还系统覆盖了队列管理器、通道配置、安全机制、JMS接口以及点对点、发布/订阅等核心概念适合从零开始安装、配置并开展实验也可作为理解IBM MQ架构与API用法的实用参考。对于刚接触消息队列的用户txt配置示例与htm说明页能快速帮助理解参数含义对于需要搭建测试环境的人员组件包也便于部署验证。1. 一个文件名里藏着多少信息做中间件这行久了拿到一个安装包第一件事不是双击运行而是先拆文件名。WS_MQ_V7.5.0.2_TRIAL_FOR_WINDOWS_ML.rar这串字符基本能把这款软件的家底交代清楚。WS_MQ 是 IBM WebSphere MQ 的缩写也就是后来改名为 IBM MQ 的那款消息中间件。V7.5.0.2 表示大版本是 7.5修复包级别到了 0.2也就是 7.5.0.2 版本。TRIAL 说明是试用版通常会附带时间限制或功能限制。FOR_WINDOWS 明确这是 Windows 平台的安装包。最后的 ML 不是 Machine Learning而是 Multi-Language多语言版本意味着安装过程中可以切换中文、英文、日文、韩文等多种界面语言。很多人看到试用版三个字就摇头觉得不如正式版踏实。但在实际企业环境里试用版的价值恰恰被低估了。我见过不止一个项目组在采购流程还没走完的时候用试用版提前把环境搭起来做 POC 验证等正式 license 下来直接无缝切换。7.5 这个版本虽然发布时间较早但在存量系统里仍然有大量部署尤其是金融、物流、制造业的核心链路里7.5 的队列管理器还在稳定运行。如果你正在维护一套老系统或者需要在一个临时环境里验证 MQ 的收发消息逻辑又或者想学习消息队列的底层机制这个安装包都能派上用场。接下来我会从安装规划、部署步骤、配置验证到踩坑排查完整走一遍基于 Windows 的 WS_MQ 7.5 试用版落地流程。这不是什么高深操作但里面的细节真不少照着做能省很多时间。2. WS_MQ 7.5 的定位为什么老版本至今仍被需要2.1 消息中间件里的老大哥WebSphere MQ 的历史可以追溯到 1993 年的 MQSeries1990 年代末被 IBM 整合进 WebSphere 产品线。7.5 版本发布于 2012 年是 MQ 历史上一个承上启下的版本它完整支持了 IPv6、TLS 1.2需要修复包配合、多实例队列管理器以及更细粒度的安全控制。虽然后面 8.0、9.0、9.1、9.2、9.3 陆续推出但很多企业的核心系统从上线起就跑在 7.5 上运维团队对它的脾气摸得透透的不到万不得已不会主动动这块压舱石。从技术指标上看7.5 的单队列管理器可支撑数万并发连接消息持久化、事务回滚、集群负载均衡这些企业级能力都已经是成熟状态。即使放在今天它的性能表现也完全够用。2.2 试用版和正式版到底差在哪试用版不是阉割版这一点很多人有误解。WS_MQ 的试用授权Trial License允许你在 90 天内免费使用完整功能包括队列管理器、MQ Explorer 图形工具、所有的 API 接口。区别只在于试用授权有时间限制到期后队列管理器仍然可以启动但会报授权过期需要卸载重装或者购买正式 license 后重新授权。试用版安装包不会自动下载修复包或安全补丁后续升级需要手动处理。正式版可以获得 IBM 官方技术支持试用版只能依靠社区和文档。所以如果你是为了学习或者做技术验证试用的功能完全没有缩水这一点可以放心。2.3 部署前的环境评估与版本选择在 Windows 上装 MQ 之前先检查三件事。第一操作系统兼容性。7.5 官方支持 Windows Server 2008 R2、2012、2012 R2以及 Windows 7 专业版/企业版。在更新的 Windows Server 2016、2019、2022 上7.5 也能跑但需要安装相应的 MSI 修复包来规避兼容性告警。如果你手头是 Windows 11 或者 10 专业版装起来问题不大但在生产环境不建议这么干。第二磁盘和内存。MQ 本身安装包不到 1GB但运行时需要日志空间和队列数据空间。建议预留至少 5GB 磁盘空间内存方面队列管理器和客户端进程加起来大概占用 300MB 到 500MB如果做压力测试按每秒几千条消息的规模估算至少准备 4GB 内存。第三端口规划。默认的队列管理器监听端口是 1414客户端连接通道使用 TCP。如果你的机器上已经有其他服务占用了这个端口安装前就要改掉。注意7.5.0.2 属于比较早期的修复级别。如果你要对接的是新版本 MQ 客户端比如 9.x 的 MQI 客户端建议在安装 7.5 基础版之后补装 7.5.0.8 以上的修复包否则客户端连接时可能出现协议不兼容的问题。3. Windows 环境下的完整安装链路3.1 解压与安装前的环境准备拿到.rar文件后先解压。这里有个细节不要用 Windows 自带的全部解压缩因为中文字符路径可能导致解压后的安装程序无法启动。建议用 7-Zip 或 WinRAR解压路径也尽量选英文目录比如D:\MQ_Install\。解压后你会看到类似下面的内容image目录存放安装镜像文件Windows目录包含安装脚本和配置模板README或Install.doc官方安装说明.rsp文件响应文件用于无人值守安装如果你在解压后的目录里找不到传统的setup.exe不要慌。MQ 7.5 的 Windows 安装入口是Setup.bat或者通过 MSI 包触发。找到image\Windows目录里面会有Setup.exe和一堆.msi文件双击Setup.exe即可进入安装向导。3.2 图形化安装步骤详解整个图形化安装过程分六个阶段每一个阶段都有需要注意的选项。第一步接受许可协议。这是试用版的重点必须勾选我接受许可证条款否则下一步按钮是灰色的。第二步选择安装类型。有典型安装、自定义安装和只安装客户端三个选项。这里要按用途区分如果你要部署完整的队列管理器选典型安装它会装上服务器组件、MQ Explorer 和开发工具包。如果你只是需要连到远程队列管理器做消息收发选只安装客户端就够了体积小、启动快。如果你要折腾集群、多实例这些高级功能选自定义安装把MQ 高级组件勾上。从实用角度出发建议选择自定义安装即使暂时用不到后面省得重新装。第三步设置安装目录和权限。MQ 推荐装在非系统盘比如D:\Program Files\IBM\WebSphere MQ。这一步还要指定 mqm 用户组。默认情况下安装程序会自动创建名为mqm的本地用户组凡是加入这个组的用户都有权限管理队列管理器。如果你是在域环境里建议额外建一个专用的域账号加进 mqm 组后面做集群或者远程管理更方便。第四步选择功能组件。这部分有十几个子选项最核心的是服务器运行时和客户端运行时。如果空间足够建议全部勾选包括 JMS 支持和 .NET 支持因为 7.5 的 JMS 客户端和 .NET 客户端在开发中非常常用。第五步预检和安装。安装程序会检查系统依赖比如是否安装了 Microsoft Visual C Redistributable。如果缺 VC 运行库安装会直接中断。遇到这种情况先去微软官网下载对应的 VC 2010 x64/x86 运行库装好后再重试。第六步安装完成后的授权配置。安装完成后打开命令提示符切换到 MQ 安装目录的bin文件夹执行setmqaut -m QM.NAME -t qmgr -p mqm all这是给 mqm 组授予队列管理器的全部权限。新装的 MQ 默认权限只允许管理员用户操作不加这条授权的话后续用非管理员用户创建队列管理器会报权限不足。3.3 无人值守安装一条命令搞定部署如果你需要批量部署多台 Windows 服务器图形化安装就太慢了。MQ 提供了响应文件安装方式一步到位。在解压目录里找到.rsp文件模板比如InstallSamples.rsp复制一份之后按实际需求修改# 安装类型1典型2自定义 INSTALL_TYPE2 # MQ 安装路径 MQ_INSTALL_ROOTD:\Program Files\IBM\WebSphere MQ # 是否创建 mqm 组1是 MQ_CREATE_GROUP1 # 安装组件多个组件用逗号分隔 MQ_COMPONENTSServer,Client,Explorer,JMS保存后以管理员身份打开命令提示符进入安装目录执行Setup.exe /s /v/qn TRANSFORMSSetupTransform.mst或者直接调用 MSI 安装包msiexec /i MQ_V7.5.0.2_Windows.msi /qb TRANSFORMSSetupTransform.mst实测下来响应文件安装整个过程大约 10 到 15 分钟比图形化快一半以上。而且响应文件可以反复调整适合做运维标准化。4. 装完之后必须做的事队列管理器与队列的配置安装完成只是第一步接下来要创建队列管理器、配置队列和通道这才能让 MQ 真正跑起来。4.1 创建队列管理器在命令提示符里输入crtmqm QM_APP这个命令会在默认位置创建名为QM_APP的队列管理器并生成对应的目录结构和日志文件。如果需要在特定路径创建数据目录可以加参数crtmqm -ld D:\MQData\QM_APP\log -md D:\MQData\QM_APP\data QM_APP-ld指定日志目录-md指定消息数据目录。生产环境建议把日志和数据分开放在不同的物理磁盘上减少 I/O 竞争。创建完队列管理器后启动它strmqm QM_APP看到WebSphere MQ queue manager QM_APP starting和WebSphere MQ queue manager QM_APP started的输出说明启动成功。4.2 创建队列和通道队列管理器启动后用runmqsc命令行工具创建队列。这个工具是所有 MQ 管理员的重度依赖用法不难但命令格式必须记牢。进入工具界面runmqsc QM_APP在runmqsc交互环境里依次输入以下命令DEFINE QLOCAL(DEV.QUEUE) MAXDEPTH(5000) DEFPSIST(YES) DEFINE CHANNEL(DEV.CHANNEL) CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER(mqm) ALTER QMGR CHLAUTH(DISABLED) ALTER QMGR CONNAUTH( )第一行创建本地队列DEV.QUEUE最大深度 5000 条消息默认持久化。第二行创建服务端连接通道DEV.CHANNEL允许 mqm 用户通过 TCP 连接。第三行和第四行是为了开发环境方便调试把通道认证和连接认证临时关闭。这里必须提醒一句CHLAUTH(DISABLED)和CONNAUTH( )在生产环境千万不能这么配。7.5 默认开启通道认证如果没做用户映射客户端连接会被拒绝。开发环境图省事可以关掉生产环境要保留认证并配置合理的用户和权限。我当时在这个坑里栽过一次测试环境关闭了认证拿到生产环境做同样操作结果安全审计直接亮红灯。退出runmqscEND4.3 用 MQ Explorer 做可视化验证命令行的方式虽然高效但新手容易晕。MQ Explorer 是 MQ 自带的图形化管理工具在开始菜单里找到WebSphere MQ Explorer打开在左侧导航栏右键队列管理器添加刚才创建的QM_APP。添加到 Explorer 后你能直观看到队列深度、通道状态、当前连接数甚至可以直接往队列里放一条消息测试。对一个刚接触 MQ 的开发者来说这个工具比命令行友好得多。我的习惯是命令行负责脚本化和批量操作Explorer 负责日常监控和临时排查两者配合使用效率最高。4.4 一个最简发送接收验证为了确认环境真的通了写一个最简单的测试。MQ 自带了一个命令行测试工具amqsput和amqsget分别用于往队列放消息和取消息。先开一个命令窗口amqsput DEV.QUEUE QM_APP输入一行消息比如hello mq按回车消息就放进去了。再按一次 CtrlZ 结束输入。再开第二个窗口amqsget DEV.QUEUE QM_APP如果能看到刚才输入的hello mq说明整条链路——队列管理器、队列、消息持久化——已经全部正常。5. 试用期内的常见坑与排查实例装 MQ 这么多年我遇到过不少看起来莫名其妙的问题这里挑几个最常见的按现象—原因—处理列出。5.1 队列管理器启动失败卡在 Starting 状态现象执行strmqm QM_APP后输出显示starting但十几秒后报错AMQ6118: WebSphere MQ queue manager could not be started or restarted。原因排查链路第一步查看错误日志。MQ 的错误日志在安装目录的errors文件夹比如D:\Program Files\IBM\WebSphere MQ\errors\AMQERR01.LOG。打开后搜索AMQ开头的错误码最常见的错误码是AMQ5540表明队列管理器权限配置有误。第二步检查 mqm 组。如果安装 MQ 时用的是管理员账号但当前执行strmqm的用户不在 mqm 组里就会启动失败。处理方法是把当前用户加入 mqm 组或者直接用安装时创建的管理员账号执行。第三步检查端口占用。虽然端口冲突通常不影响队列管理器启动但通道监听无法绑定端口时启动流程会卡住。用netstat -ano | findstr 1414查看端口是否被占用如果被占在runmqsc里修改监听端口。5.2 客户端连接报 2538 错误现象应用连接队列管理器时抛MQRC_UNKNOWN_CHANNEL_NAME(2538)明明通道名写对了。原因这个错误十有八九是通道类型不匹配。服务端连接通道SVRCONN只允许CLNTCONN类型的客户端通道连接如果服务端建的是发送通道SDR或接收通道RCVR客户端是连不上的。用DISPLAY CHANNEL(DEV.CHANNEL)查看通道类型确认是SVRCONN即可。另外一个隐藏原因7.5 的通道名称最大长度是 20 个字符。超过 20 个字符的通道名会被截断客户端就找不到实际存在的通道。命名的时候别图省事但也不要起太长。5.3 消息堆积不消费现象队列深度一直涨应用不消费或者消费极慢。排查思路先去 MQ Explorer 看队列的GET权限确认消费应用用户是否有读取权限。用到dspmqaut -m QM_APP -t q -n DEV.QUEUE -p appuser查看具体权限。如果权限正常那就是应用层面的问题。用amqsbcst或者查看应用的日志确认消费客户端是否建立了正确的会话。MQ 的消费方式有轮询和回调两种7.5 的 .NET 客户端里有两种监听模式MessageConsumer和MessageListener前者需要手动循环取消息后者是事件驱动。如果代码里用的是MessageConsumer.Receive(0)表示永久等待但循环里没有正确提交事务也会导致消息一直锁在队列里不可见表面上看起来就是不消费。5.4 中文乱码问题7.5 的 ML 多语言版自带了中文字符集支持但在 Windows 上处理中文消息时经常出现乱码。原因通常是 MQ 字符集CCSID和操作系统的代码页不一致。Windows 中文版默认字符集是 GBKCCSID 1381 或者 936而 MQ 默认使用 UTF-8CCSID 1208。当 JMS 应用发送中文文本消息时如果连接的字符串里没有显式指定字符集MQ 会按照队列管理器的默认 CCSID 编码接收端解码时就会变成乱码。解决办法有两个在客户端连接字符串里显式指定CCSID1208双方统一用 UTF-8。在队列定义上设置CCSID(1208)但这需要生产环境的队列由开发团队统一规划不能随便动。我个人的处理方式是开发阶段就在代码里固定使用 UTF-8 编码发送和接收所有环境一致。虽然系统默认字符集可能不同但应用层的编码统一了乱码问题就彻底消失了。6. 从试用走向生产版本升级与迁移建议试用版到期后如果你的系统已经完成了验证要正式上线可以考虑两条路购买正式 license 继续使用 7.5或者迁移到更高版本。我的建议是新项目尽量用新版本老项目能不动就不动。6.1 正式授权与 7.5 的扩展支持IBM 在 2018 年之后把 WebSphere MQ 改名为 IBM MQ6.0 和 7.0 已停止服务7.1、7.5 也进入了扩展支持阶段。所谓扩展支持就是只针对安全补丁和特定问题修复不再做功能性更新。如果你所在的行业有合规要求建议尽早规划升级。6.2 升级到 IBM MQ 9.x 的迁移路径从 7.5 升级到 9.x 需要做几件事第一步备份。在升级前用dmpmqcfg -m QM_APP backup.mqsc导出对象定义再用saveqmgr备份队列管理器配置。数据文件用文件系统备份的方式拷贝一份到独立磁盘。第二步选择升级方式。9.x 支持原地升级和全新部署两种方式。原地升级很简单直接运行 9.x 的安装程序选择升级现有安装安装程序会自动检测到之前 7.5 的队列管理器数据目录升级过程中会保存配置并迁移日志。第三步验证客户端兼容性。9.x 的协议默认兼容 7.5 的老客户端但如果你的客户端是 7.5 之前的版本比如 7.1 或 6.0建议同步升级客户端因为老客户端在协议协商时可能触发 COMPAT 模式性能会受影响。6.3 我的一些个人体会用了一段时间 7.5 之后最大的感受是 MQ 的核心机制这么多年几乎没有变过——队列、通道、队列管理器三大要素以及消息持久化、事务处理、集群负载均衡这些概念在 9.x 里依然适用。所以哪怕你未来正式环境用的不是 7.5通过这个试用版把 MQ 的工作机制吃透后面的学习曲线也会平缓很多。有个小建议装完试用版后除了跑通基础的 put/get一定要花时间把以下场景也验证一遍断网重启把 Windows 的网络断开看看队列管理器在监听端口不可达时是否仍然能正常处理本地消息。队列写满把MAXDEPTH故意设小往队列里打满消息观察生产者报什么错消费者恢复后消息是否自动继续流动。通道断线重连在客户端连上之后手动停掉服务端通道等待几秒再启动观察客户端是否能自动重连。这几个场景模拟了现实生产里的典型故障提前踩一遍坑后面真正上线的时候心里就有底了。关于 7.5.0.2 这个版本最后再补一句。如果你是刚接触 MQ完全没必要执着于最新版本把 7.5 安装包里的README仔细读一遍比在论坛上搜各种零散资料高效得多。官方文档里不光有安装步骤还包含了 7.5 在 Windows 上已知问题的列表和对应修复包号这些信息才是安装调试阶段最能救命的东西。本文还有配套的精品资源点击获取
