06常規MQ隊列消息的處理流程和特色

MQ隊列消息模型的特色

隊列消息模型的特色：
一、消息生產者將消息發送到Queue中，而後消息消費者監聽Queue並接收消息；
二、消息被確認消費之後，就會從Queue中刪除，因此消息消費者不會消費到已經被消費的消息；
三、Queue支持存在多個消費者，可是對某一個消息而言，只會有一個消費者成功消費。

MQ隊列消息的生產與消費常規流程

經常使用的MQ中間件產品ActiveMQ、RabbitMQ、RocketMQ等基本都是這樣的流程，具體實現上有各自的差別。規範協議實現上有JMS、AMQP或自定義規範等。

①Producer生成消息併發送給MQ（同步、異步）；
②MQ接收消息並將消息數據持久化到消息存儲（持久化操做爲可選配置）；
③MQ向Producer返回消息的接收結果（返回值、異常）；
④Consumer監聽並消費MQ中的消息；
⑤Consumer獲取到消息後執行業務處理；
⑥Consumer對已成功消費的消息向MQ進行ACK確認（確認後的消息將從MQ中刪除）。

與消息發送一致性流程的對比

一、常規MQ隊列消息的處理流程沒法實現消息發送一致性；
二、投遞消息的流程其實就是消息的消費流程，可細化。

 

可靠消息的生產與消費的正向流程

1. 主動方應用先把消息發給消息中間件，消息狀態標記爲「待確認」；
2. 消息中間件收到消息後，把消息持久化到消息存儲中，但並不向被動方應用投遞消息；
3. 消息中間件返回消息持久化結果（成功/失敗），主動方應用根據返回結果進行判斷如何進行業務操做處理：
a) 失敗：放棄業務操做處理，結束（必要時向上層返回失敗結果）；
b) 成功：執行業務操做處理；
4. 業務操做完成後，把業務操做結果（成功/失敗）發送給消息中間件；
5. 消息中間件收到業務操做結果後，根據業務結果進行處理；
a) 失敗：刪除消息存儲中的消息，結束；
b) 成功：更新消息存儲中的消息狀態爲「待發送（可發送）」；
6. 被動方應用監聽並接收「待發送」狀態的消息，執行業務處理；
7. 業務處理完成後，向消息中間件發送ACK，確認消息已經收到（消息中間件將從隊列中刪除該消息）。

總結

常規MQ隊列消息的處理流程沒法實現消息發送一致性，所以直接使用現成的MQ中間件產品沒法實現可靠消息最終一致性的分佈式事務解決方案。