一、消息隊列概述
- 消息隊列（MessageQueue，簡稱MQ）
- 本質是就是個隊列，FIFO先入先出，只不過隊列中存放的內容是message，從而叫消息隊列
- 主要用途：不同服務server、進程process、線程thread之間通信
二、使用消息隊列的場景
- ①異步處理
- ②流量控制
- ③服務解耦
- ④發佈訂閱
- ⑤高併發緩衝
①異步處理
- 使用場景有短信通知、終端狀態推送、App推送、用戶註冊等
- 以秒殺系統爲例：
- 如果不使用消息隊列（同步處理）：如果使用同步處理，那麼當用戶成功消費之後，會先寫入訂單（例如在淘寶中生成一條訂單信息），然後再通過短信通知用戶下單成功，最後再在系統中統計這條訂單信息
- 如果使用消息隊列（異步處理）：當用戶成功消費之後，將信息寫入消息隊列，然後採用一種發佈訂閱模型，消息隊列屬於發佈者，“訂單、短信、統計”三者屬於訂閱者，這樣，“訂單、短信、統計”三者可以同時從消息隊列中獲取信息，就是一種異步處理的操作了
- 優點：
- 更快速返回結果
- 減少等待，實現併發處理，提升系統總體性能
②流量控制（削峯）
- 使用消息隊列隔離網關和後端服務，以達到流量控制和保護後端服務的目的
- 例如下圖所示，在秒殺場景下：當多個用戶通過APP搶購物品，那麼就會同時向消息隊列中寫入數據，當消息隊列中數據存滿時，那麼數據就不能再寫入了，此時服務器就會給客戶端APP回送一條類似於“淘寶雙11時顯示的系統繁忙，請稍後再試”的信息，從而達到流量控制
- 擴容的概念：通過上面我們知道，當消息隊列寫滿之後，說明你的後端服務處理達到了極限，此時可以通過增加後端服務器的數量等來進行擴容，從而可以接收更多的服務器請求。如下圖所示：
③服務解耦
- 使用消息隊列實現系統的解耦
- 傳統的發佈訂閱模式中：A系統負責數據分發，D系統、B系統、D系統分別來接收數據，因爲不同系統的類型不同，因此A系統需要分別針對不同的系統調用其相關接口來對其進行服務。當有新系統加入時（例如下圖的E系統），那麼A系統就要修改源代碼，來新增對E系統的接口實現服務。這樣看來系統的耦合度太高
- 當使用消息隊列的發佈訂閱模式之後：A系統直接將內容寫入MQ中，然後其他系統也直接從MQ中讀取數據，因爲MQ的接口是統一的，因此大家使用一套就可以了。這樣就使得系統的耦合性降低
④發佈訂閱
- 比如遊戲裏面跨服：
- 廣播今天整體還剩多少把屠龍刀可以暴
- 廣播用戶暴的屠龍刀的消息
⑤高併發緩衝
- 日誌服務（kafka在日誌服務用的比較多）、監控上報
三、消息隊列的相關概念和原理
Broker
- Broker的概念來自與Apache ActiveMQ，通俗的講就是MQ的服務器
消息的生產者、消費者
- 消息生產者（Producer）：發送消息到消息隊列
- 消息消費者（Consumer）：從消息隊列接收消息
點對點消息隊列模型
- 消息生產者向一個特定的隊列發送消息，消息消費者從該隊列中接收消息
- 消息的生產者和消費者可以不同時處於運行狀態。 每一個成功處理的消息都由消息消費者簽收確認 （Acknowledge）
發佈訂閱消息模型-Topic
- 發佈訂閱消息模型中，支持向一個特定的主題Topic發佈消息，0個或多個訂閱者接收來自這個消息主題的消息
- 在這種模型下，發佈者和訂閱者彼此不知道對方。實際操作過程中，發佈訂閱消息模型中，支持向一個特定的主題Topic發佈消 息，0個或多個訂閱者接收來自這個消息主題的消息
- RabbitMQ是點對點的消息隊列模型，但是可以通過路由進行配置實現發佈訂閱。如下圖所示：
消息的順序性保證
- 基於Queue消息模型，利用FIFO先進先出的特性，可以保證消息的順序性
消息的ACK確認機制
- 即消息的Ackownledge確認機制， 爲了保證消息不丟失，消息隊列提供了消息Acknowledge機制，即ACK機制：
- 當Consumer確認消息已經被消費處理，發送一個ACK給消息隊列，此時消息隊列便可以刪除這個消息了
- 如果Consumer宕機/關閉，沒有發送ACK，消息隊列將認爲這個消息沒有被處理，會將這個消息重新發送給其他的Consumer重新消費處理
- 類似於TCP的ACK機制
消息的持久化
- 消息的持久化，對於一些關鍵的核心業務來說是非常重要的，啓用消息持久化後， 消息隊列宕機重啓後，消息可以從持久化存儲恢復，消息不丟失，可以繼續消費處理
- ZeroMQ不支持持久化，其他消息隊列支持
消息的同步和異步收發
- 同步：消息的收發支持同步收發的方式
- 同時還有另一種同步方式：同步收發場景下，消息生產者和消費者雙向應答模式，例如： 張三寫封信送到郵局中轉站，然後李四從中轉站獲得信，然後在寫一份回執信，放到中轉站，然後張三去取，當然張三寫信的時候就得寫明回信地址消息的接收如果以同步的方式（Pull）進行接收，如果隊列中爲空，此時接收將處於同步阻塞狀態，會一直等待，直到消息的到達
- 異步：消息的收發同樣支持異步方式：
- 異步發送消息，不需要等待消息隊列的接收確認
- 異步接收消息，以Push的方式觸發消息消費者接收消息
消息的事務支持
- 消息的收發處理支持事務
- 例如：在任務中心場景中，一次處理可能涉及多個消息的接收、處理，這處於同一個事務範圍內，如果一個消息處理失敗，事務回滾，消息重新回到隊列中
四、可供選擇的消息隊列產品
- 關於ZeroMQ可以參閱專欄：https://blog.csdn.net/qq_41453285/category_9981784.html
