RabbitMQ系列(八)--顺序消费模式和迅速消息发送模式

MQ使用过程中，有些业务场景需要我们保证顺序消费，而如果一个Producer，一个Queue，多个Consumer的情况下是无法保证顺序的

　　1、业务上产生三条消息，分别是对数据的增加、修改、删除，而如果没有保证顺序消费，结果可能是删除、修改、增加，本来数据最终要删除

、结果变成增加

　　2、或者是电商平台，先付钱，然后生成订单，然后通知物流（我对电商不怎么熟悉，这只是个例子而已，可能不太恰当），如果顺序改变了，

客户不付钱了，你却通知物流送货了

　　所以，这些业务场景下，消息的顺序消费很重要

　　1、一个Queue对应一下Consumer，把需要保证顺序的message都发送到一个queue当中，关闭autoack，prefetchCount=1，每次只消费

一条信息，处理过后进行手工ack，然后接收下一条message，只是由一个Consumer进行处理

　　这里说一下，如果还是多个Consumer，使用同步处理，手工ack是不行的，第一时间每个Consumer都会收到message（如果message数量>

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

巴特西