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
