消息队列总结

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

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、服务复杂度增加

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

欢迎工作一到五年的Java工程师朋友们加入Java架构开发： 854393687

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！