消息队列顺序
https://www.cnblogs.com/LipeiNet/p/9877189.html
消息队列总结
前言：关于消息队列应该大家都不陌生,在实际的项目中消息队列也无处不在,今天我和大家分享一下关于消息队列的问题。
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、服务复杂度增加
加入消息队列以后就不得不考虑消息一致性、可靠性、重复性等问题无疑加大了服务的难度
