消息队列总结

Posted 2021-02-02 lonelyxmas

原文:消息队列总结

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

1、消息队列定义

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

2、消息队列应用场景

2.1、异步处理

2.2、系统解耦

2.3、流量削峰

 

3、消息队列顺序性

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

对于生产者而言

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

对于存储端而言

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

对于消费者而言

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

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

假设我们现在想要保证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：

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

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

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

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

2、消费者响应成功

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

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

1、吞吐量不足

2、可用性低

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

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

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

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

 

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

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

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

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

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

4、消息队列重复性

 

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

5、消息队列可靠性

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

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

消息队列：如下图所示

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

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

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

6、消息队列存储

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

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

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

6、消息队列的缺点

6.1、服务可用性降低

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

6.2、服务复杂度增加

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