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