使用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唯一的一点劣势是有可能消息重复消 |
总结
所以在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升，那就得不偿失了。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。
相关文章
Java使用fastjson对String、JSONObject、JSONArray相互转换
这篇文章主要介绍了Java使用fastjson对String、JSONObject、JSONArray相互转换，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教2021-11-11
这篇文章主要介绍了Spring P标签的使用详解，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教2021-08-08
面试被问到Java泛型怎么办,有了这篇文章,让你直接保送,文中有非常详细的知识总结及相关代码示例,需要的朋友可以参考下2021-06-06
背包问题(Knapsack problem)是一种组合优化的NP完全问题。问题可以描述为：给定一组物品，每种物品都有自己的重量和价格，在限定的总重量内，我们如何选择，才能使得物品的总价格最高2022-04-04
本文主要介绍了Java处理延时任务的常用几种解决方案，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2022-05-05
这篇文章主要为大家介绍了在面试中从Hotspot源码层面来剖析java多态的实现原理，这样回答薪资随你开，有需要的朋友可以借鉴参考下，希望大家多多加薪2022-01-01
详解SpringBoot中@ConditionalOnClass注解的使用
这篇文章主要和大家详细介绍一下springboot中@ConditionalOnClass注解的用法，文中的示例代码讲解详细，感兴趣的小伙伴可以了解一下2022-08-08
本篇文章主要介绍了数据库阿里连接池 druid配置详解，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2017-05-05
偶然看到Unicode编码，觉得挺有意思，于是搜索了相关资料，准备学习学习，本文主要是一个Unicode编码的简单Java实现，需要的朋友可以了解下。2017-10-10
本教程将通过idea从svn服务器中的任意一个分支检出代码(本文采用branches)，然后再idea中创建新的分支、提交代码、拉取代码、合并分支等操作进行一一记录，暂不包含代码合并，对idea2021.1操作svn相关知识感兴趣的朋友一起学习下吧2021-05-05
最新评论