简介：本资源是一份面向中间件初学者与企业级Java/.NET开发者的IBM WebSphere MQ系统入门教程，聚焦消息队列核心原理与生产环境落地能力培养。PDF文档共217页，结构清晰、内容扎实，完整覆盖中间件概念优势、WebSphere MQ的生产者-消费者模型、统一跨平台接口设计、异步通信机制、分布式容错能力，以及队列管理器（QMGR）、本地/远程队列、通道（Channel）等关键组件的体系结构解析；配套含订单处理、支付系统、论坛发帖等典型异步场景的实践映射。资源为单文件PDF格式，大小5.5MB，轻量易读，适合作为MQ技术选型参考或中间件课程补充材料。目前已有1534人学习下载，内容从基础原理到架构认知层层递进，附有章节目标、小结与练习，便于自学巩固与快速上手。
1. 别被“消息队列”四个字吓住：它其实就像你家楼下那个永不打烊的智能快递柜
你有没有过这种经历：网购下单后，页面立刻显示“订单已提交”，但实际发货要等仓库打包、物流调度、司机装车——整个过程你根本不用盯着看，该吃饭吃饭，该睡觉睡觉。系统也没卡死在“正在发货”那一页，而是悄悄把任务塞进后台，等一切就绪再通知你。
这就是 IBM WebSphere MQ（常被简称为 IBMMQ）最核心的本事：让程序之间“错开时间说话”。它不强制两个系统必须同时在线、同时响应，而是用一个可靠的“中间信使”——队列，来暂存消息。A程序发完就走，B程序忙完再取，彼此互不打扰，也不互相拖垮。
它不是写代码的“编程语言”，也不是点几下就能用的“APP”，而是一套企业级的消息通信基础设施，专治那些“系统一多就崩”“接口一调就超时”“半夜订单积压没人管”的老毛病。适合谁？刚接触企业级系统集成的开发新手、运维同学、测试工程师，甚至想搞懂“为什么我们系统总在凌晨三点出问题”的技术负责人——只要你面对的是多个系统要协作干活的场景，这份《IBM WebSphere MQ入门教程.pdf》就是为你量身准备的第一本“人话说明书”。
2. 先搞懂一个概念：到底什么是“队列管理器”，它为什么不是“数据库”也不是“服务器进程”
很多新手第一次看到“Queue Manager”（队列管理器）这个词，下意识就去查“怎么启动MySQL服务”或者“怎么配Tomcat端口”。结果发现全不对路——IBMMQ里没有SQL语句，也不跑HTTP请求。它更像一个自带保险柜、值班表和快递员调度中心的邮局分拣站。我们拆开来看：
2.1 队列管理器 = 邮局分拣站（不是数据库，也不是Web服务器）
- 它不存业务数据：你不会用它查“用户张三的余额”，也不会用它改“订单状态为已发货”。它只管一件事：安全、有序、可追溯地收发“信封”（消息）。每个“信封”里装什么内容，由你的程序自己定义。
- 它自带“值班机制”：哪怕你的应用进程崩溃了、网络断了、服务器重启了，只要队列管理器本身还在运行，所有待发、待收的消息就稳稳躺在磁盘上，不会丢。等网络恢复、程序重连，它自动续上——这叫“持久化”和“故障恢复”，是IBMMQ区别于普通内存队列（比如Redis List）的关键。
- 它有“身份门禁”：不是谁都能往里塞信、谁都能开柜取信。每个队列、每个通道、每个连接，都要经过权限配置（比如“应用A只能往QUEUE.ORDER.IN发，不能删QUEUE.ORDER.ARCHIVE”）。这点在金融、电商类系统里不是功能，是底线。
提示：别急着去装软件。先记住这个比喻：队列管理器是“分拣站”，队列是“格子柜”，消息是“带编号的信封”，通道是“跨城市运输专线”。后面所有操作，都是围绕这四样东西展开。
2.2 三个最常被混淆的对象：队列 vs 远程队列 vs 别名队列
新手最容易在这里翻车：明明建了个队列，程序却报“队列不存在”；或者消息发出去了，但另一端死活收不到。问题往往出在没分清这三种“队列”：
| 类型 | 它是什么 | 你什么时候需要它 | 常见误用 |
|---|---|---|---|
| 本地队列（Local Queue） | 真实存在的、消息物理存放的地方。就像分拣站里一个带锁的实体格子柜。 | 你希望消息真正落地、能被持久化、能被监控积压量。 | 把它当成“转发入口”，结果消息塞进去就卡住不动了（因为没人监听它）。 |
| 远程队列（Remote Queue） | 一个“指路牌”，不存消息，只告诉队列管理器：“如果有人往这儿发，实际请转到另一个队列管理器的某个本地队列去”。就像格子柜上贴的便签：“本柜代收，转交上海分站3号柜”。 | 你要把消息发给另一台机器上的IBMMQ实例（比如测试环境发给生产环境）。 | 直接往它里面塞消息，以为能触发转发——不行！它只是个配置项，转发动作靠“发送通道”驱动。 |
| 别名队列（Alias Queue） | 一个“快捷方式”，指向另一个本地或远程队列。就像桌面图标，双击打开的是背后的真实程序。 | 你想统一程序里的队列名（比如都叫QUEUE.PAYMENT），但后端可能切换不同环境的不同真实队列。 | 以为它能做权限隔离——错！权限是按真实队列控制的，别名只是名字映射，不改变访问逻辑。 |
2.3 第一个必须亲手敲的命令：用runmqsc创建你的第一个本地队列
别跳过这一步。哪怕你只是照着敲，也要让手指记住这个节奏。打开终端（Windows用CMD/PowerShell，Linux/macOS用Terminal），假设你已安装好IBMMQ（安装步骤见教程第3章，我们先聚焦“用”）：
# 1. 进入MQ命令行工具（以管理员/有权限用户身份运行） runmqsc QMGR_NAME # 注意：QMGR_NAME 是你安装时起的队列管理器名字，比如默认可能是 QM1 或 YOURQM # 如果提示 "AMQ8060: WebSphere MQ queue manager not available"，说明队列管理器没启动，请先执行： # strmqm QMGR_NAME （Windows/Linux通用）# 2. 在 runmqsc 交互界面中，输入创建本地队列的命令（一行一条，回车执行）： DEFINE QLOCAL('QUEUE.TEST') + DESCR('我的第一个测试队列') + MAXDEPTH(5000) + DEFPSIST(YES) # 按回车后，你会看到类似 "AMQ8006: WebSphere MQ queue created." 的成功提示白话解释每行参数：
QLOCAL('QUEUE.TEST')：定义一个本地队列，名字叫QUEUE.TEST（注意单引号，名字里不能有空格）DESCR('...')：加个备注，方便以后自己或同事一眼看懂这是干啥的MAXDEPTH(5000)：这个柜子最多放5000封信，满了就拒绝新消息（防爆仓）DEFPSIST(YES)：默认所有发进来的消息都“落盘保存”，断电也不丢（强烈建议新手始终设为YES）
提示：
runmqsc是IBMMQ的“控制台”，就像MySQL的mysql命令、Redis的redis-cli。它不是脚本语言，是专用配置语言（MQSC），语法严格——+表示换行继续，末尾不能有多余空格，大小写不敏感但引号必须匹配。第一次敲错十次很正常，多试几次肌肉记忆就来了。
2.4 验证它真的建成了：三步确认法
光看到“created”不算数，得亲眼看见它在系统里呼吸：
# 1. 回到 runmqsc，执行查询命令（还是在同一个 runmqsc 会话里）： DISPLAY QLOCAL('QUEUE.TEST') # 你会看到一堆属性，重点找这两行： # AMQ8409: DISPLAY QLOCAL DETAILS. # QUEUE(TEST) TYPE(QLOCAL) MAXDEPTH(5000) ... # 说明队列存在且是本地类型 # 2. 查看队列当前状态（有多少消息在排队）： DISPLAY QSTATUS('QUEUE.TEST') # 关键字段：CURDEPTH(0) —— 当前深度为0，说明空的，健康！ # 3. （可选）用图形工具验证：如果你装了IBM MQ Explorer（教程第4章有图），打开它，连上你的QMGR_NAME，展开“Queues”，就能看到 `QUEUE.TEST` 明明静静列在那里，图标是蓝色小盒子——那是本地队列的标志。为什么这三步不能省？
因为IBMMQ的配置是“内存+磁盘双写”的。DEFINE命令写入的是磁盘配置文件，但队列管理器要读取并加载到内存才真正生效。DISPLAY命令查的是内存中的实时状态，DISPLAY QSTATUS查的是运行时数据。三者一致，才证明你不是在“纸上谈兵”。
3. 为什么非得学它？不是有Kafka、RabbitMQ吗？——从“能跑通”到“敢上线”的分水岭
你肯定搜过：“IBMMQ 和 Kafka 哪个好？”“RabbitMQ 新手友好，为啥还要碰IBMMQ？” 这问题特别实在。答案不是“哪个技术更先进”，而是“你在什么场景下，需要哪一种确定性”。
3.1 IBMMQ 的不可替代性：当“不出错”比“跑得快”重要十倍
想象一个银行转账场景：
- 用户A发起转账 → 扣减A账户余额 → 发送消息给记账系统 → 记账系统更新总账 → 返回成功 → A手机收到短信。
如果中间任何一环失败（比如记账系统临时挂了），传统同步调用会卡死，用户看到“操作超时”，A的钱可能已被扣但没记账——这是灾难。
而IBMMQ的做法是：
- 扣完A的钱，立刻把“转账指令”发进一个持久化本地队列（比如
QUEUE.TRANSFER.REQ）； - 发送成功，立刻返回用户“已受理”；
- 记账系统作为消费者，持续轮询这个队列，拿到消息就处理，处理失败就放回队列重试（或转入死信队列人工干预）；
- 整个过程，A的钱不因记账系统故障而“悬空”，系统可用性不依赖下游是否在线。
这就是IBMMQ的“事务性支持”和“死信队列”能力——它不承诺“毫秒级响应”，但承诺“消息必达、可追溯、可兜底”。Kafka擅长海量日志流，RabbitMQ轻量易上手，但它们默认不提供IBMMQ级别的企业级事务保障、跨平台二进制消息兼容、以及与大型主机（z/OS）的原生集成能力。如果你的系统要对接银行核心、社保平台、海关报关系统，IBMMQ往往是唯一被认证的“通行证”。
3.2 新手最容易低估的门槛：不是语法，是“责任边界”
学Python，写错一行print()顶多输出乱码；学IBMMQ，配错一个通道属性，可能导致：
- 消息发到一半卡在通道里，既不成功也不失败（现象：
DIS CHS(CHANNEL.NAME)显示STATUS(RUNNING)但MSG(0)）； - 权限设太松，外部程序能随意清空关键队列（现象：
CLEAR QLOCAL('QUEUE.ORDER')被非法执行）； - 日志空间配太小，高峰期直接写满磁盘导致队列管理器崩溃（现象：
AMQ7472: Log full错误，整个MQ服务停止）。
这些不是“代码bug”，而是架构责任。教程第7章讲日志、第4章讲权限、第6章讲通道，表面是操作步骤，内核是在训练你建立“系统级思维”：每一个配置项，都在定义一个责任边界——谁可以发、谁可以收、消息存多久、出错谁兜底。
3.3 一份PDF教程的价值：它帮你绕开“血泪经验”堆出来的坑
网上搜“IBMMQ 安装失败”，前10页全是“Permission denied on /var/mqm”“SELinux阻止mqm用户”“Windows服务启动不了”。这些不是技术难点，是环境适配的琐碎细节。而这本217页的PDF，第3章“系统安装”就明确列出：
- Windows上必须用管理员身份运行安装包（不是右键“以管理员身份运行”，而是登录管理员账号再装）；
- Linux上
/var/mqm目录的所有者必须是mqm组，且umask需设为022（否则新建队列权限不对）； - 安装后第一件事不是建队列，而是执行
dspmqver检查版本，再用strmqm -c QMGR_NAME带-c参数启动（启用检查点日志，避免后续恢复失败）。
它不教你“为什么Linux要改umask”，但它告诉你“这一步不做，后面90%的配置都会失败”。这就是新手最需要的：不是原理大全，而是可复现、可验证、踩过坑的路径清单。
4. 新手必踩的5个坑：从“咦？没反应”到“啊！原来是这样！”的排查指南
刚上手时，90%的“报错”都不是技术问题，而是对IBMMQ工作模式的理解偏差。下面这5条，是我带过的几十位新人反复摔过的跤，按发生频率排序，每条都附真实现象、根因和解法：
4.1 现象：runmqsc里DEFINE QLOCAL成功，但DISPLAY QLOCAL查不到
原因：队列管理器没启动，或你连错了队列管理器。runmqsc默认连接本地默认队列管理器，但如果你安装时指定了名字（如QM_TEST），而没在命令里指定，它会去找默认名（通常是QM1），自然找不到。
解决：
- 先确认队列管理器状态：
dspmq（Linux/macOS）或mqsvc（Windows服务列表）； - 如果没运行，启动它：
strmqm QM_TEST； - 启动后，用
runmqsc QM_TEST显式指定名称，再执行DEFINE； - 再
DISPLAY，必现。
4.2 现象：程序发消息报错MQRC_UNKNOWN_OBJECT_NAME (2085)
原因：程序里写的队列名，和你DEFINE的队列名大小写或空格不一致。IBMMQ队列名默认是大写，且忽略前后空格，但程序里如果写了queue.test或QUEUE.TEST，底层匹配会失败。
解决：
- 统一用大写、无空格命名（如
QUEUE.TEST）； - 在程序代码里，打印出实际使用的队列名字符串，和
DISPLAY QLOCAL结果逐字符比对； - （进阶）用
ALTER QMGR命令设置NPMCLASS(ALL)，允许小写名，但新手不建议，容易混淆。
4.3 现象：消息发进去了，CURDEPTH一直为0
原因：你发的是非持久化消息（MQPER_NOT_PERSISTENT），而队列设置了DEFPSIST(YES)，IBMMQ会静默丢弃非持久消息（不报错！）。或者，你发消息时用了错误的MQOO_OUTPUT选项，没获得输出句柄。
解决：
- 发消息前，确认队列属性：
DISPLAY QLOCAL('QUEUE.TEST')，看DEFPSIST值； - 程序中发消息时，显式设置
message.Persistence = MQC.MQPER_PERSISTENT（Java）或对应语言的持久化标志； - 用
amqsput工具测试：amqsput QUEUE.TEST QM_TEST，手动输几行文字，看CURDEPTH是否增加。
4.4 现象：远程队列发消息成功，但目标队列管理器收不到
原因：缺少关键组件——发送通道（Sender Channel）和接收通道（Receiver Channel）必须成对配置，且名称、传输协议、端口、认证方式必须完全一致。新手常只配了发送端，忘了在目标MQ上配对应的接收端。
解决：
- 在发送方QMGR：
DEFINE CHANNEL('TO.QM2') CHLTYPE(SDR) CONNAME('192.168.1.100(1414)') XMITQ('QM2.XMIT')； - 在接收方QMGR（QM2）：
DEFINE CHANNEL('TO.QM2') CHLTYPE(RCVR)； - 关键：
XMITQ参数指定的传输队列（如QM2.XMIT）必须在发送方存在且是本地队列；接收方RCVR通道名必须和发送方SDR通道名完全相同（包括大小写）； - 启动通道：
START CHANNEL('TO.QM2')（两边都要执行）。
4.5 现象：DIS QSTATUS显示CURDEPTH很高，但消费者程序没在消费
原因：消费者程序没正确开启“自动提交”或没设置MQGMO_WAIT等待模式，导致它取了一条消息就退出，下次启动又取第一条，形成“假死循环”。或者，消费者程序异常退出，消息被放回队列但未清除BackoutCount，达到阈值后进入死信队列（DLQ）。
解决：
- 检查消费者代码：是否在
get()后调用了commit()（事务模式）或close()（非事务模式）； - 用
amqsget工具手动消费：amqsget QUEUE.TEST QM_TEST，看能否取出消息； - 查死信队列：
DISPLAY QLOCAL('SYSTEM.DEAD.LETTER.QUEUE')，如果CURDEPTH > 0，说明有消息被反复投递失败，需查BackoutCount和BackoutThreshold设置。
注意：IBMMQ的“静默失败”特性（比如丢弃非持久消息不报错）是它稳定性的代价，也是新手最易懵圈的点。养成习惯：每配一个对象，立刻用
DISPLAY验证；每发一条消息，立刻用DISPLAY QSTATUS看深度；每写一段消费代码，先用amqsget手工验证通路。这三步，比背一百条命令都管用。
5. 第一个完整例子：用两行命令，实现跨机器的“你好世界”
现在，我们把前面所有概念串起来，完成一个最小但真实的跨机器消息传递。不需要写代码，只用IBMMQ自带的命令行工具，让你亲眼看到“消息如何从一台电脑飞到另一台”。
5.1 前提条件：两台机器，一个队列管理器（QM1），一个队列管理器（QM2）
- 机器A（IP: 192.168.1.100）：已安装IBMMQ，队列管理器名为
QM1，已启动； - 机器B（IP: 192.168.1.101）：已安装IBMMQ，队列管理器名为
QM2，已启动； - 两台机器防火墙开放1414端口（IBMMQ默认侦听端口）；
- （新手可先在同一台机器上模拟：用两个不同QMGR，如
QM1和QM2，CONNAME填localhost(1414)）。
5.2 步骤一：在QM2上，创建接收队列和接收通道
登录机器B，打开终端：
# 1. 进入QM2的配置界面 runmqsc QM2 # 2. 创建本地接收队列（消息最终落脚点） DEFINE QLOCAL('QUEUE.RECEIVE') + DESCR('QM2接收队列') + MAXDEPTH(1000) + DEFPSIST(YES) # 3. 创建接收通道（名字必须和QM1上发送通道名一致！） DEFINE CHANNEL('FROM.QM1') + CHLTYPE(RCVR) + TRPTYPE(TCP) # 4. 退出 END5.3 步骤二：在QM1上，创建传输队列、发送通道、远程队列
登录机器A，打开终端：
# 1. 进入QM1配置界面 runmqsc QM1 # 2. 创建传输队列（QM1的“中转站”，必须是本地队列） DEFINE QLOCAL('QM2.XMIT') + DESCR('QM2传输队列') + MAXDEPTH(1000) + DEFPSIST(YES) # 3. 创建发送通道（指向QM2的IP和端口） DEFINE CHANNEL('FROM.QM1') + CHLTYPE(SDR) + CONNAME('192.168.1.101(1414)') + # 注意：这里是QM2的IP！ XMITQ('QM2.XMIT') + TRPTYPE(TCP) # 4. 创建远程队列（指路牌：发给它，实际走FROM.QM1通道去QM2） DEFINE QREMOTE('QUEUE.REMOTE') + RNAME('QUEUE.RECEIVE') + # QM2上真实的队列名 RQMNAME('QM2') + # QM2的队列管理器名 XMITQ('QM2.XMIT') # 必须和上面定义的传输队列名一致 # 5. 启动发送通道（关键！不启动，消息发不出去） START CHANNEL('FROM.QM1') # 6. 退出 END5.4 步骤三：发消息、收消息，见证奇迹
还在机器A（QM1）上：
# 用amqsput向远程队列发消息（它会自动走通道） amqsput QUEUE.REMOTE QM1 # 终端会提示 "Sample AMQSPUT0 start"，然后光标闪烁，此时输入： Hello from QM1! # 按Ctrl+D（Linux/macOS）或Ctrl+Z（Windows）结束输入 # 你会看到 "Sample AMQSPUT0 end"，表示发送成功立刻切到机器B（QM2），执行：
# 用amqsget从本地接收队列取消息 amqsget QUEUE.RECEIVE QM2 # 你会看到： # Sample AMQSGET0 start # Hello from QM1! # Sample AMQSGET0 end发生了什么？
amqsput向QUEUE.REMOTE（远程队列）发消息；- QM1发现这是远程队列，查配置，知道要走
FROM.QM1通道，把消息放进QM2.XMIT传输队列； FROM.QM1通道（SDR类型）从QM2.XMIT取出消息，通过TCP发给192.168.1.101:1414；- QM2的
FROM.QM1通道（RCVR类型）收到，把消息放进本地QUEUE.RECEIVE； amqsget从QUEUE.RECEIVE读出——全程无需你写一行网络代码，IBMMQ自动完成路由、序列化、重试、错误隔离。
这就是IBMMQ的“魔法”：它把分布式系统的复杂性，封装成几个清晰的对象（队列、通道、队列管理器）和几条确定的命令。新手的第一个成就感，就来自亲手完成这个闭环——不是“我学会了”，而是“我造出了一个会自己走路的信使”。
6. 下一步学什么？一张从“能跑通”到“敢设计”的学习路线图
当你已经能独立完成上面的跨机器例子，恭喜，你已经越过了IBMMQ最大的心理门槛。接下来，不是狂刷更多命令，而是按“解决问题”的顺序，一层层加固你的能力地基。我给你画了一张真实可用的路线图，每一步都对应一个具体场景、一个必须掌握的技能点，以及教程里对应的章节页码（基于217页PDF）：
6.1 第一阶段：守住底线——让消息“不死、不丢、不乱”（1~2周）
这是上线前的生死线，必须100%掌握：
| 场景 | 必须学会的操作 | 教程位置 | 关键检查点 |
|---|---|---|---|
| 消息不丢 | 配置日志：计算LOGPRIMARY和LOGSECONDARY大小，确保能撑过峰值2小时；设置LOGWRITE为ASYNC提升性能 | 第7章 P90-92 | DIS QMGR查LOGPRIMARY(3)LOGSECONDARY(2)；dspmqlog -m QM1确认日志文件存在 |
| 消息不死 | 设置死信队列（DLQ）：创建SYSTEM.DEAD.LETTER.QUEUE，为关键队列设BOQNAME和BOTHRESH | 第4章 P62, 第7章 P95 | DISPLAY QLOCAL('QUEUE.ORDER')查BOQNAME(SYSTEM.DEAD.LETTER.QUEUE)BOTHRESH(5) |
| 消息不乱 | 启用消息分组（Message Grouping）：用MsgSeqNumber和GroupID保证同一笔订单的所有消息按序处理 | 第4章 P59（事务支持） | 发送端设message.GroupId，消费端用MQGMO_GROUP标志获取 |
从那以后我每次新建生产队列，都强制走一遍这三查：
DIS QLOCAL看BOQNAME、DIS QMGR看日志、DIS CHL看通道HBINT（心跳间隔）是否合理。少一次，就可能埋一个半夜被call醒的雷。
6.2 第二阶段：看清全局——用监控和日志，把黑匣子变成透明玻璃房（1周）
IBMMQ不是黑匣子，只是默认不说话。教会它“汇报工作”，是你成为可靠运维的关键：
| 工具 | 你能看到什么 | 怎么用（一句话） | 教程位置 |
|---|---|---|---|
runmqsc+DISPLAY系列 | 实时队列深度、通道状态、连接数 | DIS QSTATUS(*)查所有队列积压；DIS CHS(*)查所有通道是否RUNNING | 第4章 P51-54 |
dmpmqlog | 解析日志文件，定位某次消息失败的具体时间点和错误码 | dmpmqlog -m QM1 -t 20240501.120000导出指定时间日志 | 第7章 P98 |
MQ Explorer（图形工具） | 可视化队列积压曲线、通道流量图、告警事件 | 安装后连上QMGR，右键队列→“Browse Messages”直接看消息内容 | 第4章 P55（含截图） |
我第一次线上事故，就是靠
dmpmqlog导出凌晨2点的日志，发现AMQ9208: Connection failed连续出现，立刻查防火墙策略——而不是瞎猜“是不是程序bug”。工具不是炫技，是给你一双透视眼。
6.3 第三阶段：主动出击——用触发器（Triggering）让系统学会“自己动手”（2~3天）
别再写定时脚本轮询队列了！IBMMQ的触发器机制，能让队列“有消息就喊你”，这才是真正的异步精髓：
# 在QM1上，为QUEUE.ORDER.IN配置触发器 DEFINE QLOCAL('QUEUE.ORDER.IN') + TRIGDATA('start_order_processor.sh') + # 消息到达时执行的脚本 TRIGMPRI(5) + # 触发优先级 TRIGTYPE(FIRST) # 第一条消息就触发 # 创建触发器进程定义（告诉MQ这个脚本在哪） DEFINE PROCESS('ORDER.PROCESSOR') + APPLTYPE(UNIX) + # Linux脚本 APPLICID('/opt/mq/scripts/start_order_processor.sh')然后，只要QUEUE.ORDER.IN里有第一条消息，IBMMQ就会自动拉起start_order_processor.sh，传入队列名等参数。你的脚本只需专注业务逻辑，不用管“何时启动、何时停止、消息取多少”。
从那以后我每次设计新流程，第一反应不是“写个服务”，而是“能不能用触发器驱动”。它让系统更轻、更可靠、更符合IBMMQ的设计哲学——把控制权交给消息，而不是轮询。
希望帮到你。
本文还有配套的精品资源，点击获取
