消息队列mq的使用场景,MQ消息机制
目录
MQ介绍使用MQ的优缺点，什么时候使用MQ消息模型，什么是JMS，为什么需要JMS点对点模型，两种模型的区别，以及MQ在工作中的应用场景。MQ的异步使用“由MQ引起的问题”、“MQ产品的比较”和“MQ的测试点”生产者-消费者队列摘要
00-1010根据某学科的介绍，MQ(message queue)又称消息队列，是基础数据结构中的一种先进先出的数据组织。
一般用于解决应用解耦、异步消息、流量裁剪等问题。并实现高性能、高可用性、可扩展和最终一致的架构。
名词解耦的解释简单来说就是积木。一切都是相互独立的。比如汉堡、面包、肉饼，都是相互独立的，可以单独使用。也可以组合成一个食物异步买汉堡。下单后，他们就去玩手机，等服务员打电话。这就是所谓的异步。同步就是下单后，在服务员叫号之前，你不能做别的事情。大家9点上班，地铁进不去。在门口，限制电流和削峰遵循的原则是，最终到达数据库的请求数量应该尽可能少。比如1/2的人下午开始工作，有部分停电。有兴趣可以查看一下要传递的削峰填谷消息的内容，比如说说话，写信。形式不重要。根据双方约定的格式，queue是一种先进先出的数据结构。排队打疫苗，从队尾排队，从队头排队。MQ的主要产品有RabbitMQ、ActiveMQ、RocketMQ、ZeroMQ、Kafka。
通过以上内容，我们不难发现MQ是一种跨进程的通信机制，用来传递上下游的消息。个人觉得MQ有点像中介。房东发布租房信息，信息放在中介，租客通过中介来租房。
00-1010以一个通俗点为例：
希望HR这个面试官尽快招到合适的人选，所以一开始是这样的：
HR问面试官什么时候有空，发了候选人信息，亲自看了面试官看完给出结论才走。时间长了，大家都觉得很麻烦。HR觉得应聘者不错，面试官觉得不合适，容易产生纠纷。
后来HR跟面试官说，我把资料放桌子上了。有空记得看，然后每次面试官看到桌上的资料都会拿起来看。
在这个场景中，HR是生产者，面试官是消费者，桌子是MQ。
MQ的优势是解决应用程序解耦、异步消息和流量剪裁：
HR要给资料的时候，不需要知道面试官有没有空，只需要把资料放在桌子上，这样大家就有时间去做其他的事情，节省大家的时间。通过应用解耦，每个成员都是独立的，不受其他成员的影响。面试官不在乎谁放的信息，HR不在乎谁看的信息。如果其他群体有招聘需求(而且是同一工种，比如Java后端开发)，HR还是把资料放在桌子上，两个面试官只需要从桌子上拿资料做参考。异步消息，HR只要把资料放在桌子上就可以做其他的事情，比一开始亲自看效率高很多。HR不需要关注面试官什么时候看资料，也不需要关注看资料多久，减少矛盾。削峰，HR给信息的频率不固定，面试官看信息的时间长短也不固定。面试官只需要在固定的时间内看完结论，就不会有那么大的压力。
00-1010名词解释复杂度的引入“表”是使用MQ后多出来的东西。它需要一个放桌子的地方，过程会更长更复杂。不一致HR会认为面试官应该已经看过材料了，但实际面试官可能还没有开始看，这就导致了不一致的问题。但是，在一个约束良好的时间内，面试官最终的咨询状态必须与HR的认知一致。这就是所谓的终极不一致。降低了系统的可用性。如果桌子坏了，后面的过程会不会中断？当然，使用MQ还有很多问题需要解决，比如信息的无辜丢失，同样的信息给了很多份，信息被抢，原始信息给了面试官A，结果给了面试官B，等等。
00-1010名词说明生产者不需要得到消费者的反馈。HR根本不需要关注。默认面试官有，否则只能采取监督阅读的方式来允许不一致。HR可能会发现，有时候面试官说看过材料，其实并没有看。只有HR愿意相信面试官最终看完的时候能有效解耦。提速带来的收益大于摆放书桌的成本。这意味着它是有效的。比如你只有一个月甚至半年的简历，不如直接当面给。
MQ介绍
使用 MQ 的好处
JAVA消息服务是指用于两个应用程序之间异步通信的API。它为标准消息协议和消息服务提供了一组公共接口，包括创建、发送、读取消息等。用于支持Java应用程序开发。
00-1010在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工作场景消息模型的资料请关注盛行IT其它相关文章！
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。