SpringCloud-快速了解消息队列

最新推荐文章于 2024-04-28 09:32:24 发布

置顶我在风花雪月里等你

最新推荐文章于 2024-04-28 09:32:24 发布

阅读量3.2k

点赞数 10

分类专栏： # SpringCloud 文章标签： Java SpringCloud 消息队列

本文链接：https://blog.csdn.net/weixin_44807144/article/details/103150853

版权

SpringCloud 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

前言

说起消息队列，可能大家感觉既熟悉又陌生。因为消息和队列是耳熟能详的概念，但连在一起又好像没有见过，本文就带大家了解一下消息队列，希望能帮大家在脑海中建立一个雏形。消息队列中间件是分布式系统的重要的组件，对于消息队列中间件在SpringCloud中的应用会在另外一篇文章中和大家分享交流（ps：我个人倾向于娓娓道来、长短合适的文章，所以分两篇来讲）。

一、消息队列介绍

消息队列，英文全名MessageQueue（MQ）。先说说这个消息，指的是在程序之间传送的数据，比如字符串，复杂一点，可能包含嵌入对象，而消息队列顾名思义就是在消息的传输过程中保存消息的队列，就像下图：在这里插入图片描述补充一下：
将消息放入队列的功能模块称为生产者，取出消息的功能模块称为消费者。

二、为什么需要消息队列

消息队列的出现就是为了解决生产者和消费者交互过程中出现的问题，请看下面的生活案例：

小时候最开心莫过过年了，大年初一拜完年后，手头有了充足的资金，就号召一堆小伙伴向小卖铺浩浩荡荡开进。一到小卖铺的窗口就七嘴八舌开来，买鞭炮的、买辣条的、买乱七八糟的都有…老板也是怕了我们，一时间也应付不过来，大家也是闹成一团。十多年过去了，科技发展太快了，小卖铺母鸡变凤凰，摇身一变成了无人超市。又到过年了，多年前的那批孩子们都已经长大了，读书的、工作的甚至成家的都有，这次他们又聚到了一起来这家买东西，每个人都迅速的挑选了自己要的商品，然后再自己用支付宝扫码付款，一起有说有笑地离去。

这个小小的生活故事，也是我们80后、90后和一部分00后的真实写照，故事中就增加了货柜这个类似消息队列的东西，情况发生巨大改变，交易效率大大提高。这类例子在生活中比比皆是，比如菜鸟驿站等快递点，你不需要在上班时间去拿快递，提高了网购体验。总结来说，消息队列就是一个第三方平台，避免了生产者和消费者的直接关联。

三、消息队列的三大作用

消息队列有三大作用，解耦、异步和削峰（限流）。

解耦

从之前的案列。从这个案例中，我们可以把超市货架当做一个消息队列，消息就是商品，老板是生产者，孩子们是消费者。在小卖铺阶段，孩子们的需求增加或者修改时，老板就要去拿取不同的商品，这样孩子们和老板必须一对一交易，耦合严重，这违背了我们JAVA基本设计准则—高内聚、低耦合。而做出改进后，老板只需要将商品放到货架中，孩子们根据需要自己拿，这样大大降低了孩子们和老板的耦合度。

异步

       异步意为不同步，接收方不知道发送方什么时候发送消息，两者独立运行。
       如下图这个案列：
在这里插入图片描述
       A系统需要发送个请求给B系统处理,由于B系统需要查询更新数据库花费时间较长,以至于A系统要等待B系统处理完毕后再发送下个请求,造成A系统资源浪费.使用消息队列后,如下图所示，A系统生产完消息后直接丢进消息消息队列,就完成一次请求,继续处理下个请求。这样就实现了生产者和消费者互不干扰彼此的运行，达到异步的效果。
在这里插入图片描述

削峰（限流）

        削峰意为在访问量可能出现峰值的情况下，为了避免服务器崩溃，加以限制处理。削峰在生活中也是处处可见，比如早高峰、晚高峰，为了避免交通系统崩溃，采用单双号限行处理；地铁站中，限流入站，这个我深有感触，每天早上一大堆人挤在入口前，定时放入一批人进站。由此可见，削峰在各行各业都有着重要应用。

       我们还是结合例子来看看，因为我对大学时期的教务系统深恶痛绝，就以它为例。某天下午两点，根据通知教务系统将在三点开启公共选修课的预选，各个宿舍楼的寝室里面，每个人都打开了自己的电脑，个个摩拳擦掌，都对中意的课程势在必得。当时钟转到下午三点的那一刻，每个人都在点击登录按钮或者敲击Enter键，结果只见弹出提示窗：当前访问的人数较多，请稍后再试，更多的人前仆后继的想进去，然后一个小时后，系统彻底崩溃了。

       我们假设教务系统的服务器集群有两个服务器，每台每秒可以处理1000个请求，当选课开启后，每秒有3000个请求，结果可想而知，系统崩溃了。如果现在增加了一个消息队列，如下图所示：
在这里插入图片描述
       改进过后，请求先入消息队列，而不是由业务处理系统直接处理，做了一次缓冲，服务器A、B根据各自处理能力，去消息队列取相应数量的请求进行处理，暂时没有处理的请求就在消息队列中等待，避免了大流量冲垮系统。

四、消息队列的两种模式

消息队列包括两种模式，点对点模式（point to point， queue）和发布/订阅模式（publish/subscribe，topic），这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费。

点对点模式

也称P2P模式，包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。
在这里插入图片描述
点对点模式特点：

第三方是每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；
发送者和接收者间没有依赖性，发送者发送消息后，消息直接存储在消息队列中，接收者是否在线并不影响发送；
接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；

发布/订阅模式

包含三个角色主题（Topic），发布者（Publisher），订阅者（Subscriber）多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

在这里插入图片描述
发布/订阅模式

每个消息可以有多个消费者；
发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能接收发布者的消息；
为了消费消息，订阅者必须保持运行的状态；

五、常用的消息队列

常用的四种MQ：RabbitMQ/ActiveMQ/RocketMQ/Kafka，各有优缺点。

RabbitMQ

RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ 一定是你的首选。

ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。

RocketMQ

RocketMQ出自阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

文档相对来说简单一些，然后接口这块不是按照标准 JMS 规范走的有些系统要迁移需要修改大量代码，适合有一定技术实力的公司。

Kafka

Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，之后成为Apache项目的一部分。

kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。