MQ工作场景消息模型

MQ介绍

根据某科的介绍，MQ(message queue)，叫消息队列，是基础数据结构中先进先出的一种数据机构。

一般用来解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。

名词	解释
解耦	简单说就是积木化，每个东西都相互独立，比如汉堡包，面包跟肉饼是相互独立，可以单独使用，也可以组合成一个食物
异步	去买汉堡包，下单之后就去玩手机，等服务员叫号通知领取，这就叫异步；而同步是下单后，什么都不能干，直到服务员叫号才能做其他事
限流	大家 9 点上班，地铁进不去，门口做限流
削峰	遵从最后落地到数据库的请求数要尽量少的原则，比如让 1/2 的人下午开始上班、局部停电，感兴趣可以查看削峰填谷
消息	要传输的内容，比如说话、写信，形式不重要，按照双方约定的格式即可
队列	是一种先进先出的数据结构，排队打疫苗，从队尾入队，从队头出队

MQ 主要产品包括：RabbitMQ、ActiveMQ、RocketMQ、ZeroMQ、Kafka

通过上述的内容，不难发现，MQ是一种跨进程的通信机制，用于上下游传递消息，而个人觉得MQ有点像中介， 房东发布出租信息，信息放在中介处，租客来通过中介来租房子。

使用 MQ 的好处

举个通俗点的例子：

面试官希望 HR 早点招聘到合适的人选，于是一开始是这样的：

HR 问面试官什么时候有空，把候选人资料送过去，并且亲自看到面试官看完并给出结论后才离开，时间一长，大家都觉得很麻烦，HR 觉得候选人不错，面试官觉得不合适，容易发生争执。

后面，HR 跟面试官说，我把资料放在桌子上，你有空记得看，然后每次面试官看到桌子有资料后，都会拿起来看。

在这个场景上，HR就是生产者，面试官就是消费者，桌子就是MQ。

使用MQ带来的好处是解决应用解耦，异步消息，流量削锋：

• HR想给资料时，无需知道面试官是否有空，只需要把资料放桌子上即可，这样大家都有时间做别的事，节省大家的时间。。应用解耦，每个成员都是独立的，不受其他成员影响。面试官不关心谁放的资料，HR 不关心谁哪个面试官看的资料
• 如果别的组也有招聘需求（且当是同一工种，比如 Java 后端开发），HR依然把资料放在桌子上，两个面试官只需要各自从桌子上取资料查阅即可。异步消息，HR 把资料放在桌子上即可，就可以去做别的事，比一开始亲自看着的效率高太多了
• HR无需关注面试官什么时候查看资料，也不关注看资料用多长的时间，减少矛盾。流量削峰，HR 给资料的频率不固定，面试官看资料的时长也不固定，面试官只需要在固定时间内看完给结论即可，不会有那么大的压力。

使用 MQ 的坏处

名词	解释
引入复杂度	「桌子」这东西是使用 MQ 后多出来的，需要有地方放桌子，而且流程会变长，更复杂
不一致性	HR会以为面试官应该看了资料，但实际面试官可能还没开始看，这就导致了不一致性的问题，但在约束好的时间内，面试官最终的查阅状态与HR的认知必须是要一致的，这就是所谓的最终不一致性
系统可用性降低	如果桌子坏了，后面的流程是不是就中断了

当然，使用MQ还有很多问题要解决，比如资料无辜丢了、一样的资料，给了好多份、资料被抢、本来资料给面试官 A，结果给到面试官 B等场景都是需要处理的。

什么时候用 MQ

名词	解释
生产者不需要从消费者处获得反馈	面试官到底看了没有，HR 根本不需关注，默认面试官是看了，否则就只能采取监督看完的方式
容许不一致性	HR 可能会发现有时候面试官说看了资料，但实际没看的情况，只有 HR 愿意相信面试官最后看了即可
有效	解耦、提速等带来的收益大于放置书桌是有成本的，那说明是有效的。比如一个月甚至半年才有一份简历，那还不如直接当面给更高效

消息模型

什么是 JMS

Java 消息服务指的是两个应用程序之间进行异步通信的 API，它为标准消息协议和消息服务提供了一组通用接口，包括创建、发送、读取消息等，用于支持 JAVA 应用程序开发。

为什么需要 JMS　

在JAVA中，如果两个应用程序之间对各自都不了解，甚至这两个程序可能部署在不同地方上，那么它们之间如何发送消息呢？

举个例子，一个应用程序 A 部署在印度，另一个应用程序部署在美国，然后每当 A 触发某件事后，B 想从 A 获取一些更新信息。

当然，也有可能不止一个 B 对 A 的更新信息感兴趣，可能会有 N 个类似 B 的应用程序想从 A 中获取更新的信息。

在这种情况下，JAVA提供了最佳的解决方案-JMS，完美解决了上面讨论的问题。

点对点模型

在该模型中，有下列概念：
消息队列 (Queue)、发送者 (Sender)、接收者 (Receiver)

每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到它们被消费或超时。

• 支持存在多个消费者
• 每个消息只有一个消费者（一旦消息被消费，消息就不再在消息队列中）
• 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
• 接收者在成功接收消息之后需向队列应答成功

如果希望发送的每个消息都应该被成功处理的话，那么就需要点对点模型。

女神想找备胎 A 聊天，就单聊备 A，这就是点对点，只有一个人能收到消息

发布订阅模型

消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。。

在该模型中，有下列概念：
主题（Topic）、发布者（Publisher）、订阅者（Subscriber）

客户端将消息发送到主题。多个发布者将消息发送到 Topic，系统将这些消息传递给多个订阅者。

• 每个消息可以有多个消费者
• 发布者和订阅者有时间依赖性，只有当客户端创建订阅后才能接受消息，且订阅者需一直保持活动状态以接收消息
• 订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。

如果希望发送的消息可以不被做任何处理、或者被一个消费者处理、或者可以被多个消费者处理的话，那么可以采用 Pub/Sub 模型。。

女神发了个朋友圈，她的备胎们都能看到，这就是发布/订阅。

两个模型之间的区别

点对点模型下，不可重复消费。

点对点下，一个队列可以有多个消费者，生产者发送一条消息到队列，消费者能用队列取出并且消费消息，一旦消息被消费后，队列不再有存储，所以其他消费者不能消费到已经被消费的消息，如果一直没有消费者处理，这条消息就会被保存，直到有可用的消费者为止。

发布订阅模型，可以重复消费。

发布订阅下，发布者发送到 topic 的消息，只有订阅了 topic 的订阅者才会收到消息，注意是所有订阅这个 topic 的服务都能收到，所以能达到消息拷贝的效果

MQ 的在工作上应用场景

虽然上面以一个招聘的例子来讲解 MQ 的应用场景，但可能还是会有疑问，不知道工作上是如何的，因此再讲讲工作上的场景。

异步

之前负责的一个需求叫老带新，大致流程如下：

1）用户下单后，会先判断下单者身份

2）如果是新用户，再判断是否有邀请人

3）如果有，再判断邀请人身份

4）如果是老用户，就给双方发积分

这样的话，用户的流程就会发生变化：

很明显，这样做的问题是：新增的逻辑存在堵塞下单主流程的风险。

既然同步处理会有问题，那就改异步吧，改完变成这样：

异步的好处是，即使老带新逻辑有问题，也不会堵塞下单流程。

这样的好日子没过几天，问题又来了：老带新业务频繁改动，导致下单系统频繁发版本，存在质量隐患。

使用 MQ

由于依赖订单系统的业务越来越多，为了保证下单系统的稳定性，业务层面必须解耦，只需要把支付成功的消息告诉别的业务，他们收到了通知后自行处理，我们只管自己的流程，后续还有其他业务系统，直接订阅我们发送的支付成功消息。

「MQ 带来的问题」

• 如何保证消息队列的高可用？
• 如何保证消息不被重复消费？
• 如何处理消息丢失的问题？
• 如何保证消息的顺序性？
• 如何处理消息队列大量消息积压？

上面这些问题，都是实际工作上会遇到的，往往也都是测试点，下面也会有提及到，简单了解下即可。

「MQ 产品的对比」

产品	单机吞吐量	时效性	可用性	消息可靠性	功能支持
ActiveMQ	万级	毫秒级	高	较低概率出现丢失数据	极其完备
RabbitMQ	万级	微妙级	高	基本不丢	erlang 开发
RocketMQ	十万级	毫秒级	非常高	可配置 0 丢失	分布式
Kafka	十万级	毫秒级	非常高高	可配置 0 丢失	分布式

而在选择上，一般公司都是用Kafka跟RocketMQ较多。

「MQ 的测试点」

生产者

• 生成的数据格式是否跟定义的一致
• 数据是否有成功推送到队列里
• 数据是否有成功推动到对应的 topic
• 推送失败时如何处理
• 重复推送同一条数据，如何处理
• 不同顺序推送消息，注意队列优先级
• 推消息耗时
• 队列容量达到上限，无法推送后如何处理

消费者

• 消费的消息是否来自订阅的 topic
• 消息被消费了，是否有清除
• 生产者推送过快，消费速度过慢（堵塞），会如何
• 无法消费没订阅的 topic 消息
• 生产者推送消息后，消费者接受到的消息内容跟生产者推的一致
• 如何处理重复消息，比如幂等
• 处理超时
• 消息处理失败
• 消费消息的优先级是否跟推的一致
• 消费消息耗时
• 消费者宕机，消息堆积，无人处理，会如何处理
• 是否能正常消费消息

队列

• 宕机恢复后，消息是否丢失
• 宕机预案，多久能恢复，如果无法恢复的预案
• 不同的消息格式，是否能正常识别及转发

小结

来来去去，花了一周的时间来整理这堆信息，之前有测过mq，但没有太了解这玩意，从介绍、选型、测试点，加深了对 mq 的印象，但由于没做过 mq 的性能测试跟自动化测试，所以这块暂时没有心得能输出，如果后续有类似的经历，也会分享下。

本文留下了一个悬念，针对消息不一致的问题，大家是怎么解决的，这边非常好奇，所以下篇计划会写分布式事务，想深入了解下细节~更多关于MQ工作场景消息模型的资料请关注其它相关文章！