使用MQ消息队列的优缺点详解
前言
公司的项目一直都是在使用MQ的，但是由于使用的功能很简单，所以一直都是知其然不知其所以然，作为一个程序猿有必要了解每一个使用的技术，为什么使用它？它的优点是什么？缺点是什么？等等。。。
使用mq的好处
解耦与复用
系统A要发送一个消息到多个系统，如果此时每增加一个系统，系统A都需要通过修改源码来增加接口，此时耦合非常高，但是如果中间使用消息队列的话，系统只需要发送一次到消息队列，别的系统就能复用该信息，当增加或删除系统调用接口的时候，不需要额外的更新代码。
异步
用户调用一个接口的时候，可能该接口调用了别的方法。例如：用户注册的时候，后台可能需要调用：查询数据库，插入数据库，发送邮件，发送用户指南等等...
但是用户可能并不需要后台将所有的任务执行完毕，那么此时在初入数据口后面加入mq队列，用户就能很快得到注册成功的响应而去做一些别的事情。mq的机制又能保证最终的一致性，所以使用起来很安全很稳定。
消峰
何为消峰，就是当系统压力过大的时候，让系统压力减小。如何做？
加入数据库的读写每秒3000，在高峰期，系统的访问达到了每秒10000。此时由于加入了消息队列，所以不会出现激增的访问导致系统奔溃。
（注意，晓峰并不会让用户的等待时间减少，所以一般会跟异步搭配来使用）
使用mq的缺点
增加了复杂度与降低了可用性
本来系统之间直接通行调用接口就行了，但是引入了mq导致系统的复杂度大大增加，并且如果mq挂掉了，那么系统之间的通信就中断了，导致整个系统的全部挂掉。
一致性问题
A系统处理完了发送到消息对流后直接返回成功了，用户以为你这个请求就成功了；但是问题是，其他系统消费该消息后，如果当中有一个系统出现了问题，导致数据丢失。最后就会发生数据不一致等问题。
常见的mq的区别
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，吞吐量比RocketMQ和Kafka要低了一个数量级 | 万级，吞吐量比RocketMQ和Kafka要低了一个数量级 | 10万级，RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| topic数量对吞吐量的影响 | topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降这是RocketMQ的一大优势，在同等机器下，可 | topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降这是RocketMQ的一大优势，在同等机器下，可 | ||
| 时效性 | ms级 | 微秒级，这是rabbitmq的一大特点，延迟是最低的 | ms级 | 延迟在ms级以内 |
| 可用性 | 高，基于主从架构实现高可用性 | 高，基于主从架构实现高可用性 | 非常高，分布式架构 | 非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 经过参数优化配置，可以做到0丢失 | 经过参数优化配置，消息可以做到0丢失 | |
| 功能支持 | MQ领域的功能极其完备 | 基于erlang开发，所以并发能力很强，性能极其好，延时很低 | MQ功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准 |
| 优劣势总结 | 非常成熟，功能强大，在业内大量的公司以及项目中都有应用偶尔会有较低概率丢失消息而且现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用 | erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备而且开源提供的管理界面非常棒，用起来很好用社区相对比较活的。RabbitMQ吞吐量会低一些，这是因为他做的实现机制比较重。erlang开发很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。 | 接口简单易用，而且毕竟在阿里大规模应用过，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性是ok的，还可以支撑大规模的topic数量。阿里出品都是java系的，我们可以自己阅读源码。 | kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消 |
总结
所以在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升，那就得不偿失了。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持小牛知识库。
-
Jboot 内置了对MQ消息队列的功能支持，使用MQ需要以下几步步骤。 第一步：配置jboot.properties文件，内容如下： # 默认为redis (支持: redis,activemq,rabbitmq,hornetq,aliyunmq等 ) jboot.mq.type = redis jboot.mq.channel = channel1,channel2,channel3 jboot
-
本文向大家介绍Python中线程的MQ消息队列实现以及消息队列的优点解析，包括了Python中线程的MQ消息队列实现以及消息队列的优点解析的使用技巧和注意事项，需要的朋友参考一下 “消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。相
-
面试题 为什么使用消息队列？ 消息队列有什么优点和缺点？ Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 面试官心理分析 其实面试官主要是想看看： 第一，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从
-
主要内容：1 什么是MQ,2 为什么要用 MQ （作用、功能）,3 MQ 的分类,4 MQ 的选择1 什么是MQ MQ（message queue），从字面意思来看，本质是一个队列，FIFO 先入先出，只不过队列中存放的内容是 message 而已，还是一种跨进程的通信机制，用于上下游传递消息。 在互联网架构中，MQ 是一种非常常见的上下游 “逻辑解耦 + 物理解耦” 的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ ，不用依赖其他服务。 2 为什么要用 MQ （作用、功能）
-
System.Dead.Letter.Queue中有2条消息。我如何查看这些消息，以便能够看到它们有什么问题？ 我在IBM的网站上读到，你可以这样做： 但是当我运行这个时，我会得到以下错误： 谢谢
-
本文向大家介绍windows消息和消息队列实例详解，包括了windows消息和消息队列实例详解的使用技巧和注意事项，需要的朋友参考一下 本文详细讲述了windows消息和消息队列的原理与应用方法。分享给大家供大家参考。具体分析如下： 与基于MS - DOS的应用程序不同，Windows的应用程序是事件(消息)驱动的。它们不会显式地调用函数（如C运行时库调用）来获取输入，而是等待windows向它们