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