没用过MQ消息队列，只能先了解一下

最新推荐文章于 2024-07-22 22:58:19 发布

一点都看不懂Java

最新推荐文章于 2024-07-22 22:58:19 发布

阅读量882

点赞数 16

分类专栏： Java 文章标签： java java-rabbitmq java-activemq java-rocketmq kafka

本文链接：https://blog.csdn.net/m0_60945024/article/details/140152690

版权

Java 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

什么是MQ消息队列

消息中间件（MOM），用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。本文主要讲消息队列，消息队列（Message queue 即MQ）是在消息的传输过程中保存消息的容器。MQ负责两个系统之间传递消息，这两个系统可以是异构的，处于不同硬件、不同操作系统、用不同语言编写，只需要简单配置、以及简单的调用几个MQ的API，就可以互相通讯，你不必考虑底层系统和网络的复杂性，MQ能够应付多种异常情况，例如网络阻塞、临时中断等等；消息队列主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。使用较多的消息队列有ActiveMQ，RocketMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ等，部分数据库如 Redis、MySQL 以及 phxsql 也可实现消息队列的功能。

为什么要用消息队列

说来惭愧，小编到现在干的项目都体量小，没有那么高的并发量，用不着消息队列，很难受，只有在实习的时候参与过一个项目用到过，可惜那会一点也看不懂Java，轮不到我去参与，只写了一些简单的功能，但旁边的同事负责的系统再用，每天听他们聊这些，我只好把之前学过的一些知识点总结一下，希望对大家有点用吧

使用消息队列（MQ，Message Queue）的主要原因有以下几个：

解耦系统组件：消息队列将生产者和消费者分离，一个应用程序（如订单创建系统）作为生产者发送消息，而另一个应用（如库存管理系统）作为消费者接收并处理这些消息。这样即使两个系统同时运行，变更也不会相互影响。
异步处理：通过消息队列，可以处理那些需要时间响应的任务。比如用户请求生成报告，可以直接返回响应给用户，然后后台通过队列慢慢生成报告，提高了用户体验。
流量控制与削峰填谷：高峰期时，消息队列可以帮助系统缓冲大量的请求，避免服务器瞬间过载。在低峰期，又可以从队列中逐渐取出并处理任务。
可靠性保证：消息队列提供了消息持久化和重试机制，确保重要信息不会丢失或因故障而无法处理。
扩展性和灵活性：通过增加消息队列节点，可以轻松地水平扩展处理能力，满足业务增长需求。
服务间的通信：在一个分布式系统中，多个服务可能需要协调工作，消息队列提供了一种标准化的通信方式，使得各服务之间可以独立部署和升级。

消息队列的优点缺点

优点

MQ的使用场景有很多，但是比较核心的就是：解耦、异步、削锋。

①解耦：

传统模式：系统间耦合性太强，如有ABCD四个系统，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦

中间件模式：将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。

②异步：

传统模式：一些非必要的业务逻辑以同步的方式运行，太耗费时间。

中间件模式：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度。

③削锋：

传统模式：并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常。

中间件模式：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的，假如消息队列的长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。

有个例子能清晰解释什么是削锋，疫情期间各大线上商城APP里面的口罩被抢购一空，在这种情况下，某商城开启了一场每晚八点的抢口罩的活动，每天下午三点进行预约，晚上八点抢购，最初第一天，抢购的时候，一百多万预约，到八点抢购估计也能有百万的并发量，可是第一天八点抢购的时候，由于并发量太高，直接把某商城服务器弄崩了，直接报了异常，可能某商城在上线这个活动的时候也没能够想到会有那么高的并发，打了一个猝不及防，但是这只是在开始一两天出现报异常的情况，后面却没有再出现异常信息，到后来再抢购只是响应的时间变得很慢，但是某商城系统并没有崩溃，这种情况下一般就是用了MQ（或者之前用了MQ，这次换了个吞吐量级别更高的MQ），也正是利用了MQ的三大好处之一——削峰。

缺点

①系统可用性降低：

系统引入的外部依赖越多，系统要面对的风险越高，拿场景一来说，本来ABCD四个系统配合的好好的，没啥问题，但是你偏要弄个MQ进来插一脚，虽然好处挺多，但是万一MQ挂掉了呢，那样你系统不也就挂掉了。
②系统复杂程度提高：

非要加个MQ进来，如何保证没有重复消费呢？如何处理消息丢失的情况？怎么保证消息传递的顺序？问题太多。
③一致性的问题：

A系统处理完再传递给MQ就直接返回成功了，用户以为你这个请求成功了，但是，如果在BCD的系统里，BC两个系统写库成功，D系统写库失败了怎么办，这样就导致数据不一致了。
所以，消息队列其实是一套非常复杂的架构，你在享受MQ带来的好处的同时，也要做各种技术方案把MQ带来的一系列的问题解决掉，等一切都做好之后，系统的复杂程度硬生生提高了一个等级。

主流的MQ消息队列

目前业界四大主流的MQ有ActiveMQ、kafka、RocketMQ、RabbitMQ。其他的MQ也有，不过比较冷门，感觉也不用了解那么多，就不用多说了。

ActiveMQ

优点：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，消息可靠性较低的概率丢失数据
缺点:官方社区现在对 ActiveMQ 5.x 维护越来越少，高吞吐量场景较少使用。

Kafka

大数据的杀手锏，谈到大数据领域内的消息传输，则绕不开 Kafka，这款为大数据而生的消息中间件，以其百万级 TPS 的吞吐量名声大噪，迅速成为大数据领域的宠儿，在数据采集、传输、存储的过程中发挥着举足轻重的作用。目前已经被 LinkedIn，Uber, Twitter, Netflix 等大公司所采纳。
优点: 性能卓越，单机写入 TPS 约在百万条/秒，最大的优点，就是吞吐量高。时效性 ms 级可用性非常高，kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用,消费者采用 Pull 方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;有优秀的第三方Kafka Web 管理界面 Kafka-Manager；在日志领域比较成熟，被多家公司和多个开源项目使用；功能支持：功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用
缺点：Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长，使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试；支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢；

RocketMQ

RocketMQ 出自阿里巴巴的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。被阿里巴巴广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场景。
优点:单机吞吐量十万级,可用性非常高，分布式架构,消息可以做到 0 丢失,MQ 功能较为完善，还是分布式的，扩展性好,支持 10 亿级别的消息堆积，不会因为堆积导致性能下降,源码是 java 我们可以自己阅读源码，定制自己公司的 MQ
缺点：支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟；社区活跃度一般,没有在 MQ核心中去实现 JMS 等接口,有些系统要迁移需要修改大量代码

RabbitMQ

2007 年发布，是一个在 AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
优点:由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，MQ 功能比较完备,健壮、稳定、易用、跨平台、支持多种语言如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持 AJAX 文档齐全；开源提供的管理界面非常棒，用起来很好用,社区活跃度高；更新频率相当高
官网：https://www.rabbitmq.com/
缺点：商业版需要收费,学习成本较高

总结

看到这么多优缺点，只能感慨一句没有最好的技术，只有最适合的技术，感觉可以先了解一下，万一哪天能用上一点呢，没用过确实是纸上谈兵了，哈哈，工作了之后就有些摆烂了，其实大家还是可以平常多看看，什么都能看。消息队列的一些知识就先介绍到这儿吧，哪天小编自己用上了可能会有更多的理解吧，我真的是一点也看不懂Java啊！