為什麼需要訊息佇列
削峰
業務系統在超高併發場景中，由於後端服務來不及同步處理過多、過快的請求，可能導致請求堵塞，嚴重時可能由於高負荷拖垮Web伺服器。
為了能支援最高峰流量，我們通常採取短平快的方式——直接擴容伺服器，增加服務端的吞吐量。
優點是顯而易見的，短時間內吞吐量增加了好幾倍，甚至數十倍。缺點也明顯，流量低峰期伺服器相對較閒。
訊息佇列（比如 Apache RocketMQ，Apache Kafka），也是目前業界比較常用的手段
解耦
不同的業務端在聯合開發功能時，常常由於排期不同、人員調配不方便等原因導致專案延期。其實，其根本原因是業務耦合過度。
上下游系統之間的通訊是彼此依賴的，所以不得不協調上下游所有的資源同步進行，跨團隊處理問題顯然比在團隊內部處理問題難度大。
你是否依稀記得另一個團隊的同事呼叫你的API，你告訴他發個請求過來，你打斷點一步一步除錯程式碼的場景？
你是否記得為了協調開發資源、QA 資源，以及協調上線時間等所做的一切，你被老闆罵了多少次，最後還是延期了：我們依賴他們，他們的QA說，高峰期不讓釋出。
加入訊息佇列後，不同的業務端又會是何種情況呢？上下游系統進行開發、聯調、上線，彼此完全不依賴，也就是說，系統間解耦了
非同步
處理訂票請求是一個漫長的過程，需要檢查預訂的車次是否有預訂數量的票、下單扣庫存、更新快取等一系列操作。這些耗時的操作，我們可以透過使用訊息佇列的方式，把提交請求成功的訊息告訴使用者
資料一致性
訊息系統的優點：
（1）免去了多次重試（發起請求）的複雜邏輯。
（2）免去了處理過多重試請求的壓力。
（3）即使服務不可用，業務也不受影響。
常見訊息佇列
| 訊息佇列名字 | Apache ActiveMQ | Apache Kafka | Apache RocketMQ |
|---|---|---|---|
| 產生時間 | 2007 | 2012 | 2017 |
| 貢獻公司 | Apache | 阿里巴巴 | |
| 當時流行MQ | JMS | ActiveMO | Kafka，ActiveMO |
| 特性 | (1)支援協議眾多:AMOP,STOMP，MOTT，JMS (2)訊息是持久化的JDBC |
(1)超高寫入速率 (2)end-to-end 耗時毫秒級 |
(1)萬億級訊息支援 (2)萬級Topic數量支援 (3)end-to-end耗時毫秒級 |
| 管理後臺 | 自帶 | 獨立部署 | 獨立部署 |
| 多語言客戶端 | 支援 | 支援 | Java、C++、Python、Go、C# |
| 資料流支援 | 不支援 | 支援 | 支援 |
| 訊息丟失 | 理論上不會丟失 | 理論上不會丟失 | 理論上不會丟失 |
| 文件完備性 | 好 | 極好 | 極好 |
| 商業公司實踐 | 國內部分企業 | 阿里巴巴 | |
| 容錯 | 無重試機制 | 無重試機制 | 支援重試，死信訊息 |
| 順序訊息 | 支援 | 支援 | 支援 |
| 定時訊息 | 不支援 | 不支援 | 支援 |
| 事務訊息 | 不支援 | 支援 | 支援 |
| 訊息軌跡 | 不支援 | 不支援 | 支援 |
| 訊息查詢 | 資料庫中查詢 | 不支援 | 支援 |
| 重放訊息 | 不清楚 | 暫停重放 | 實時重放 |
| 當機 | 自動切換 | 自動選主 | 手動重啟 |