MQ使用过程中,有些业务场景需要我们保证顺序消费,而如果一个Producer,一个Queue,多个Consumer的情况下是无法保证顺序的
举例:
1、业务上产生三条消息,分别是对数据的增加、修改、删除,而如果没有保证顺序消费,结果可能是删除、修改、增加,本来数据最终要删除
、结果变成增加
2、或者是电商平台,先付钱,然后生成订单,然后通知物流(我对电商不怎么熟悉,这只是个例子而已,可能不太恰当),如果顺序改变了,
客户不付钱了,你却通知物流送货了
所以,这些业务场景下,消息的顺序消费很重要
解决方案:
1、一个Queue对应一下Consumer,把需要保证顺序的message都发送到一个queue当中,关闭autoack,prefetchCount=1,每次只消费
一条信息,处理过后进行手工ack,然后接收下一条message,只是由一个Consumer进行处理
这里说一下,如果还是多个Consumer,使用同步处理,手工ack是不行的,第一时间每个Consumer都会收到message(如果message数量>
![](/qrcode.jpg)
consumer数量),剩余的message才会等到ack之后发送过来,所以还是无法保证顺序消费
2、上面的解决方案只是个人一些简单理解,真正的生产环境的方案很复杂,下面是大神的解决方案
需要保障以下几点:
1、发送的顺序消息,必须保证在投递到同一个队列,且这个消费者只能有一个(独占模式)
2、然后同意提交(可以合并一个大消息,或拆分多个消息,最好是拆分),并且所有消息的会话ID一致
3、添加消息属性:顺序表及的序号、本地顺序消息的size属性,进行落库操作
4、并行进行发送给自身的延迟消息(带上关键属性:会话ID、SIZE)进行后续处理消费
5、当收到延迟消息后,根据会话ID、SIZE抽取数据库数据进行处理即可
6、定时轮询补偿机制,对于异常情况
备注:比如生产端消息没有完全投递成功、或者消费端罗渡异常导致消费端落库后缺少消息条目的情况
解释:
左边的步骤和之前讲的批量消息完全相同
右边步骤:
1、接收到多条消息之后,首先不是进行逻辑处理,而是直接分别入库,把第一条消息入库的同时,发送一个延迟消息(例如5分钟,用来
保障所有的消息都接受到,进行统一处理),监听到延迟消息之后,根据sessionId和size查出一共多少条消息,然后根绝消息顺序去处理(
例如,起一个线程去处理)
PS:接收到消息一定是先进行入库,在经过延迟消息接收过后,再进行处理
个人对这个方案理解不深,可以自行理解。。。
迅速消息发送模式
1、迅速消息是指消息不进行落库,不做可靠性保障
2、适合日志数据、统计分析业务
3、优点就是性能和吞吐量达到最大
图例:
消息不进行落库,Producer不需要Broker进行confirm