MQ是Message Queue消息队列的缩写

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。

以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景

场景说明：汽车触发围栏报警后，需要发送报警邮件和报警短信。传统的做法有两种1.串行的方式；2.并行方式。

串型：串行方式：将报警信息写入数据库成功后，发送报警邮件，再发送报警短信。以上三个任务全部完成后，该报警信息加入统计列表。并行方式：报警信息写入数据库成功后，同时发送报警邮件和短信。

假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）。小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？引入消息队列，将不是必须的业务逻辑，异步处理。改造后的架构如下：

场景介绍，在spring cloud分布式微服务项目中，工单管理和设备管理分别是两个微服务，如果A工单被张三接单了，那么工单状态要设为已派单，检验员设为张三，设备状态要置为在检。

传统的做法是，先调用工单管理的工单更新接口，成功之后再调用设备管理的设备更新接口，成功之后再返回操作提示给用户。这样做的缺点是应用耦合，如果在派单操作的时候正好设备管理微服务挂了或者阻塞了，那么派单操作就会失败或者要等待很长时间无反馈。另外如果设备管理的接口有变动，那么工单管理里面的代码也要改动。

引入消息中间件，派单的时候，工单管理的工单更新接口处理好后把信息写入消息队列，然后直接返回操作反馈给用户。不管工单管理服务正不正常，正常就从消息队列里订阅消息处理，不正常就等待回复正常后再订阅消息处理。

场景介绍，XX公司的系统原来是针对A地区的客户开发的，现在为了抢占市场，拿下了B和C两个地区的客户，那么新系统上线，就存在如何把B和C的基础数据导入XX公司的系统中来的问题，短时间内要把庞大的旧数据改造适合新系统再导入进来，这很容易使系统挂掉，另外每天还有增量数据产生。

这时可以引入消息中间件，B和C的客户只要负责把数据规则放到消息队列里就好了，XX公司可以有条不紊的从消息队列里订阅数据，可以有效缓解短时间内的高流量压力，但是这也对消息中间件的可靠性提出了要求。

类似聊天室的功能。

原文作者：June

原文链接：https://jatshw.com/2018/05/10/MQ-%E7%AE%80%E4%BB%8B/

发表日期：May 10th 2018, 10:35:03 am

更新日期：March 21st 2023, 9:55:43 pm

版权声明：本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可