關於消息隊列的故事
有一天，產品跑來說：“我們要做一個用戶註冊功能，需要在用戶註冊成功後給用戶發一封成功郵件。”
小明（攻城獅）：“好，需求很明確了。” 不就提供一個註冊接口，保存用戶信息，同時發起郵件調用，待郵件發送成功後，返回用戶操作成功。沒一會功夫，代碼就寫完了。驗證功能沒問題後，就發佈上線了。
線上正常運行了一段時間，產品匆匆地跑來說：“你做的功能不行啊，運營反饋註冊操作響應太慢，已經有好多用戶流失了。”
小明聽得一身冷汗，趕緊回去改。他發現，原先的以單線程同步阻塞的方式進行郵件發送，確實存在問題。這次，他利用了 JAVA 多線程的特性，另起線程進行郵件發送，主線程直接返回保存結果。測試通過後，趕緊發佈上線。小明心想，這下總沒問題了吧。
沒過多久，產品又跑來了，他說：“現在，註冊操作響應是快多了。但是又有新的問題了，有用戶反應，郵件收不到。能否在發送郵件時，保存一下發送的結果，對於發送失敗的，進行補發。”
小明一聽，哎，又得熬夜加班了。產品看他一臉苦逼的樣子，忙說：“郵件服務這塊，別的團隊都已經做好了，你不用再自己搞了，直接用他們的服務。”
小明趕緊去和郵件團隊溝通，誰知他們的服務根本就不對外開放。這下小明可開始犯愁了，明知道有這麼一個服務，可是偏偏又調用不了。
郵件團隊的人說，“看你愁的，我給你提供了一個類似郵局信箱的東西，你往這信箱裏寫上你要發送的消息，以及我們約定的地址。之後你就不用再操心了，我們自然能從約定的地址中取得消息，進行郵件的相應操作。”
後來，小明才知道，這就是外界廣爲流傳的消息隊列。你不用知道具體的服務在哪，如何調用。你要做的只是將該發送的消息，向你們約定好的地址進行發送，你的任務就完成了。對應的服務自然能監聽到你發送的消息，進行後續的操作。這就是消息隊列最大的特點，將同步操作轉爲異步處理，將多服務共同操作轉爲職責單一的單服務操作，做到了服務間的解耦。
哈哈，這下能高枕無憂了。太年輕，哪有萬無一失的技術啊~
不久的一天，你會發現所有業務都替換了郵件發送的方式，統一使用了消息隊列來進行發送。這下僅僅一個郵件服務模塊，難以承受業務方源源不斷的消息，大量的消息堆積在了隊列中。這就需要更多的消費者（郵件服務）來共同處理隊列中的消息，即所謂的分佈式消息處理。
官方定義
消息隊列（英語：Message queue）是一種進程間通信或同一進程的不同線程間的通信方式，軟件的貯列用來處理一系列的輸入，通常是來自用戶。消息隊列提供了異步的通信協議，每一個貯列中的紀錄包含詳細說明的數據，包含發生的時間，輸入設備的種類，以及特定的輸入參數，也就是說：消息的發送者和接收者不需要同時與消息隊列互交。消息會保存在隊列中，直到接收者取回它。 ——維基百科
架構模型
看一個簡單的架構模型：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-P4QjajkY-1577500647089)(D:\github\reading-notes\images\mq_01.png)]
producer是消息的生產者，負責產生和發送消息到broker；
broker是消息處理中心，負責消息的存儲，確認，重試等，一般其中會包含多個queue；
consumer是消息的消費者，負責從broker中獲取消息，並進行相應的處理。
特性
異步性
將耗時的同步操作，通過發送消息的方式，進行了異步化處理，減少了同步等待的時間。
鬆耦合
消息隊列減少了服務之間的耦合性，不同的服務可以通過消息隊列進行通信，而不用關心彼此的實現細節，只要定義好消息的格式就可以。
分佈式
通過對消費者的橫向擴展，降低了消息隊列阻塞的風險，以及單個消費者產單點故障的可能性，消息隊列本身也可以做成分佈式集羣。
可靠性
消息隊列一般會將接收到的消息存儲在磁盤上，這樣即使應用掛掉，或者消息隊列本身掛掉，消息也能夠重新加載。
什麼時候不用消息隊列？
消息隊列的不足之處，主要包括：
- 系統中多了一個消息組件，系統更復雜；
- 消息傳遞的路徑變的更長，增加消息傳遞的延時；
- 消息的可靠性與重複性互爲矛盾，消息不丟失，不重複難以同時保證；
- 消息的生產者無法知道消息的消費者對消息的處理結果。
因此，調用方實時依賴執行結果的業務場景，使用調用，而不使用消息隊列。
什麼時候使用消息隊列？
需要使用消息隊列的場景包括：
- 數據驅動型的任務依賴；
- 消息的生產者不關心消息的消費者的執行結果；
什麼時候使用消息隊列？
需要使用消息隊列的場景包括：
- 數據驅動型的任務依賴；
- 消息的生產者不關心消息的消費者的執行結果；
- 異步返回執行的時間比較長。
