消息队列总结（转）

我会带着你远行 2021-12-22 13:39 291阅读 0赞

**转自：**https://www.cnblogs.com/LipeiNet/p/9877189.html

**作者：**朝向远方

**作者博客：**https://www.cnblogs.com/LipeiNet/

前言：关于消息队列应该大家都不陌生,在实际的项目中消息队列也无处不在,今天我和大家分享一下关于消息队列的问题。

# 1、消息队列定义 #

消息队列大家又经常称为MQ(message queue),从字面的含义来看就是一个存放消息的容器。

# 2、消息队列应用场景 #

## 2.1、异步处理 ##

![549734-20181030175004936-264955811.jpg][]

**2.2、系统解耦**

![549734-20181030175153442-1984394895.jpg][]

**2.3、流量削峰**

![549734-20181030175246896-94933750.jpg][]

# 3、消息队列顺序性 #

提到mq那么我们必然会讨论mq顺序性问题,比如生产者发送消息1,2,3...对于消费者必须按照1,2,3...这样的顺序来消费,那么消息队列应该怎么样去考虑这样事情呢,有人说了消息队列是先进先出不就保证了顺序性,其实并非如此,而且想通过队列来保证顺序性是非常困难的,那么我们来看看为什么说非常困难的。

**对于生产者而言**

比如生产者连续发送1、2、3但是不久2和3返回结果成功,唯独1返回结果是失败,这个时候如果我们重发1那么顺序肯定就会乱了。

**对于存储端而言**

消息队列不可能分区进行存储,也就是一个topic的消息只能采用一个队列存储,如果一个topic采用多个队列就不可能保证顺序

**对于消费者而言**

对于消费端来说还不可以并行消费,也就是不可以开启多线程或者多个客户端来进行消费

## 3.1、消息队列顺序性分析1： ##

![549734-20181030193048319-349243589.png][]

假设我们现在想要保证s1和s2两条消息顺序被消费可能想设计如上图所示,假定生产者先发送s1然后在发送s2,如果想保证s1先被消费,那么需要s1到达消费端后在通知mq2,然后mq2在发送消息。但是其实这是理想的模型,可能会出现如下2个问题

1、s1不一定要比s2先到mq集群(比如网络延迟)

2、s2到达mq集群并且已经消费完毕,s1还没到达mq集群,这就会出现乱序

所有我们想要s1比s2先消费最简单粗暴的方式就是s1和s2发送同一台server上,这样根据队列先进先出原则,肯定s1要比s2先消费

## 3.2、消息队列顺序性分析2： ##

![549734-20181030201228130-202026448.png][]

但是这种模型仅仅是理论上的可行,因为可能出现网络延迟,比如s2比是s1先到达消费端,我们同样无法保证消息的顺序,这样一来我们可能发送s1等消费者响应后然后在发s2。

## 3.3、消息队列顺序性分析3： ##

![549734-20181030202003105-190176266.png][]

但是我们知道消费者可能出现2种情况

1、消费者没有响应(可能消费成功没有响应,也可能消费失败没有响应)

2、消费者响应成功

对于没有响应的mq集群可以进行重发消息,如果消费成功重发就会导致消息重新处理,这样一来就会带来新的问题,重复问题下面说

综上我们可以得出想保证消息顺序性最简单可行方式就是生产者->mq->消费者这样一一对应关系,但是同样会带来如下2个问题

1、吞吐量不足

2、可用性低

## 3.4、消息队列顺序性分析4： ##

任何设计都离不开业务的本身,我们可以从业务来考虑顺序消息

1、不关注乱序的应用实际大量存在

2、队列无序不表示消息无序

![549734-20181030210147186-1407626886.png][]

注释：对于同一种消息放入同一个队列中,同一种消息可以通过topic主题来进行标记。

综上我们可以可以总结出来为了保证消息的顺序性要从生产者、存储端、消费者三个角度来考虑

1、生产端必须保证消息成功发送以后才能继续发送第二条

2、存储端必须要求同一种消息必须存放在同一个队列中

3、消费端不可以采用并发消费

# 4、消息队列重复性 #

![549734-20181030210948279-670101623.png][]

消息重复由业务端来保证如上图

# 5、消息队列可靠性 #

生产者：ack确认机制消息重发

消费者：手动ack确认,消息重新请求,或者重试等

消息队列：如下图所示

1、对于业务方进行限流,避免恶意刷消息

2、服务器采用负载均衡避免一台服务宕机而不可用

3、消息采用持久化,避免断电等原因导致消息丢失

![549734-20181030211238284-1414556853.png][]

# 6、消息队列存储 #

消息队列存储一般采用逻辑存储和物理存储如下图所示

1、逻辑存储放入内存,主要存储偏移量、消息主题等,同时将存储内容刷入磁盘避免丢失

2、物理采用文件进行存储,定期对文件进行归档

![549734-20181030211247448-515490765.png][]

# 6、消息队列的缺点 #

6.1、服务可用性降低

加入消息队列后,如果出现mq集群宕机,那么就可能会导致服务不可用

6.2、服务复杂度增加

加入消息队列以后就不得不考虑消息一致性、可靠性、重复性等问题无疑加大了服务的难度

转载于:https://www.cnblogs.com/SupPilot/p/10213794.html

[549734-20181030175004936-264955811.jpg]: /images/20211220/76ba9cb87fbc4facb825a733a15fd827.png
[549734-20181030175153442-1984394895.jpg]: /images/20211220/2634045651a244bc9ca338209584f208.png
[549734-20181030175246896-94933750.jpg]: /images/20211220/1746d67e1b4e4a5792da59731b890ddd.png
[549734-20181030193048319-349243589.png]: /images/20211220/9489dc3c0249461daaea51bed537383f.png
[549734-20181030201228130-202026448.png]: /images/20211220/5a68dcbd79b341c6810915412c9d77c4.png
[549734-20181030202003105-190176266.png]: /images/20211220/cdccaf7ac8ed4da6b33f1b5fc571e6ab.png
[549734-20181030210147186-1407626886.png]: /images/20211220/780c19734e34465cb0a928cb3b5c4c97.png
[549734-20181030210948279-670101623.png]: /images/20211220/62c2885e56de46b0a9ba100455540942.png
[549734-20181030211238284-1414556853.png]: /images/20211220/791d70930c574bf88027d2054caf4557.png
[549734-20181030211247448-515490765.png]: /images/20211220/96c88c6f765d454181148ff85a04b391.png