在面試大型網際網路公司的時候，很可能會被問到訊息佇列的問題：
1.在何種場景下使用了訊息中介軟體？
2.為什麼要在系統裡引入訊息中介軟體？
3.如何實現冪等？
鏈式呼叫是我們在寫程式時候的一般流程，為了完成乙個整體功能，會將其拆分成多個函式（或子模組），比如模組a呼叫模組b，模組b呼叫模組c，模組c呼叫模組d。但在大型分布式應用中，系統間的rpc互動繁雜，乙個功能背後要呼叫上百個介面並非不可能，這種架構有如下幾個劣勢：
1、 這些介面之間耦合比較嚴重，每新增乙個下游功能，都要對上有的相關介面進行改造；舉個例子：假如系統a要傳送資料給系統b和c，傳送給每個系統的資料可能有差異，因此系統a對要傳送給每個系統的資料進行了組裝，然後逐一傳送；當**上線後，新增了乙個需求：把資料也傳送給d。此時就需要修改a系統，讓他感知到d的存在，同時把資料處理好給d。在這個過程中你會看到，每接入乙個下游系統，都要對a系統進行**改造，開發聯調的效率很低。其整體架構如下圖：
2、面對大流量併發時，容易被沖垮。每個介面模組的吞吐能力是有限的，這個上限能力如果堤壩，當大流量（洪水）來臨時，容易被沖垮。
3、存在效能問題。rpc介面基本上是同步呼叫，整體的服務效能遵循「木桶理論」，即鏈路中最慢的那個介面。比如a呼叫b/c/d都是50ms，但此時b又呼叫了b1，花費2000ms，那麼直接就拖累了整個服務效能。
根據上述的幾個問題，在設計系統時可以明確要達到的目標：
1、要做到系統解耦，當新的模組接進來時，可以做到**改動最小；
2、設定流量緩衝池，可以讓後端系統按照自身吞吐能力進行消費，不被沖垮；
3、強弱依賴梳理，將非關鍵呼叫鏈路的操作非同步化，提公升整體系統的吞吐能力，比如上圖中a、b、c、d是讓使用者發起付款，然後返回付款成功提示的幾個關鍵流程，而b1是通知付款後通知商家發貨的模組，那麼實質上使用者對b1完成的時間容忍度比較大（比如幾秒之後），可以將其非同步化。
在現在的系統視線中，mq訊息佇列是普遍使用的，可以完美的解決這些問題的利器。下圖是使用了mq的簡單架構圖，可以看到mq在最前端對流量進行蓄洪，下游的系統a\b\c只與mq打交道，通過事先定義好的訊息格式來解析。
引入mq之後的系統架構、互動方式與最初的鏈式呼叫架構非常不同，雖然可以解決上文提到的問題，但也要充分理解其原理特性來避免其帶來的***，這裡以訊息佇列如何保證「訊息的可靠投遞」為切入點，來看看mq的實現方式。
1. client如何將訊息可靠投遞到mq
1.client傳送訊息給mq
2.mq將訊息持久化後，傳送ack訊息給client，此處有可能因為網路問題導致ack訊息無法傳送到client，那麼client在等待超時後，會重傳訊息；
3.client收到ack訊息後，認為訊息已經投遞成功。
2.mq如何將訊息可靠投遞到client
1.mq將訊息push給client（或client來pull訊息）
2.client得到訊息並做完業務邏輯
3.client傳送ack訊息給mq，通知mq刪除該訊息，此處有可能因為網路問題導致ack失敗，那麼client會重複訊息，這裡就引出消費冪等的問題；
4.mq將已消費的訊息刪除
為什麼要使用訊息中介軟體
假設乙個訂單在整個交易系統會經歷如下兩個步驟 a 訂單建立 b 訂單出庫 整個過程，如下圖所示 但是現在有了新需求，我們需要在統計訂單的建立資料，便於在雙11的時候用於分析實時系統下單總銷量，就像天貓雙11大螢幕那樣展示當前時刻的單量和銷售額。你想到了乙個方案對建立訂單的介面進行了一系列的更改，改完...
為什麼要使用MQ訊息中介軟體？它解決了什麼問題？
場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊,傳統的做法有兩種1.序列的方式 2.並行的方式 1 序列方式 將註冊資訊寫入資料庫後,傳送註冊郵件,再傳送註冊簡訊,以上三個任務全部完成後才返回給客戶端。這有乙個問題是,郵件,簡訊並不是必須的,它只是乙個通知,而這種做法讓客戶端等待沒有必要等待的東西...
訊息中介軟體 MQ
1 為什麼需要訊息佇列mq 因為在高併發環境下，由於來不及同步處理，請求往往會發生阻塞，比如 大量的insert，update語句請求同時到達mysql，直接導致無數的行鎖鎖表，甚至最後的請求會堆積過多，從而觸發too many connections錯誤。通過使用訊息佇列，可以非同步的處理請求，從...