最近小L會聽到很多學員說，在面試大型互聯網公司的時候，很可能會被問到消息隊列的問題：
- 在何種場景下使用了消息中間件?
為什么要在系統里引入消息中間件?
如何實現冪等?
鏈式調用是我們在寫程序時候的一般流程，為了完成一個整體功能，會將其拆分成多個函數(或子模塊)，比如模塊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在最前端對流量進行蓄洪，下游的系統ABC只與MQ打交道，通過事先定義好的消息格式來解析。
引入MQ之后的系統架構、交互方式與最初的鏈式調用架構非常不同，雖然可以解決上文提到的問題，但也要充分理解其原理特性來避免其帶來的副作用，這里以消息隊列如何保證“消息的可靠投遞”為切入點，來看看MQ的實現方式。
一、Client如何將消息可靠投遞到MQ
- 1.Client發送消息給MQ
2.MQ將消息持久化后，發送Ack消息給Client，此處有可能因為網絡問題導致Ack消息無法發送到Client，那么Client在等待超時后，會重傳消息;
3.Client收到Ack消息后，認為消息已經投遞成功。
二、 MQ如何將消息可靠投遞到Client
- 1.MQ將消息push給Client(或Client來pull消息)
2.Client得到消息并做完業務邏輯
3.Client發送Ack消息給MQ，通知MQ刪除該消息，此處有可能因為網絡問題導致Ack失敗，那么Client會重復消息，這里就引出消費冪等的問題;
4.MQ將已消費的消息刪除
