消息隊列MQ是大型分佈式系統不可缺少的中間件，也是高併發系統的基石中間件，其重要性不言而喻。
本篇通過圖文並茂的方式，對消息隊列MQ來完整詳解，助你快速掌握消息隊列 MQ 最內核的東西，譬如：消息隊列MQ的主流應用場景、主流產品與選型、以及設計一個消息隊列MQ該如何下手等。
建議收藏備用！
——不囉嗦了，下面進入正文！嘀嘀！準備上車了！！——
消息隊列MQ概述
消息隊列（Message Queue，簡稱MQ），指保存消息的一個容器，本質是個隊列。
消息（Message）是指在應用之間傳送的數據，消息可以非常簡單，比如只包含文本字符串，也可以更復雜，可能包含嵌入對象。
下圖便是消息隊列的基本模型，向消息隊列中存放數據的叫做生產者，從消息隊列中獲取數據的叫做消費者。
消息隊列MQ應用場景
1.異步處理
消息隊列的主要特點是異步處理，主要目的是減少請求響應時間，實現非核心流程異步化，提高系統響應性能。
舉一個用戶註冊的例子，用戶註冊成功後，系統需要發送注短信註冊成功通知，以及贈送註冊成功的積分。
1）同步
同步的總耗時：10ms+100ms+100ms=210ms
由於短信通知與增加積分爲非核心流程，爲了提升系統響應性能，從而我把它改造爲異步。
2）異步
改造後就變成上圖，之前需要等用戶註冊10ms+短信通知100ms+增加積分100ms才能返回，現在把短信通知和增加積分改爲異步的形式，用戶註冊後寫入消息10ms左右立即返回成功給客戶端，無需等待耗時較久的同步(短信+積分)就可以返回，從而極大地提升了系統的吞吐量。
所以異步的典型場景就是將比較耗時而且不需要即時（同步）返回結果的操作，通過消息隊列來實現異步化。
2.應用解耦
使用了消息隊列後，只要保證消息格式不變，消息的發送方和接收方並不需要彼此聯繫，也不需要受對方的影響，即解耦。
每個成員不必受其他成員影響，可以更獨立自主，只通過消息隊列MQ來聯繫，典型的上下游解耦如下圖所示：
3.流量削鋒
流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
這種場景中系統的峯值流量往往集中於一小段時間內，所以爲了防止系統在短時間內的峯值流量沖垮，往往採用消息隊列來削弱峯值流量，相當於消息隊列做了一次緩衝。
4. 日誌處理
日誌處理是指將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。
消息隊列MQ設計
1. 整體架構
上圖爲整體架構，會涉及三類角色：
1）Producer 消息生產者：負責產生和發送消息到 Broker；
2）Broker 消息處理中心：負責消息存儲、確認、重試等，一般其中會包含多個 queue；
3）Consumer 消息消費者：負責從 Broker 中獲取消息，並進行相應處理；
2. 詳細設計
詳細的流程如上圖，producer發送給broker,broker發送給consumer,consumer回覆消費確認，broker刪除/備份消息等。
1）RPC 通信
圖上的第一個步驟:Producer生產消息向Broker發送會涉及通信的問題，同樣Consumer 消費消息也會涉及通信的問題。
上圖中的Producer,Broker,Consumer最後就通過RPC將數據流串起來了，所以需要解決通信的問題。
你可以基於Netty 來做底層通信，用 Zookeeper、Euraka 等來做註冊中心，然後自定義一套新的通信協議。
也可以直接利用成熟的 RPC 框架 Dubbo 或者 Thrift 實現即可，這樣不需要考慮服務註冊與發現、負載均衡、通信協議、序列化方式等一系列問題了。
2）Broker存儲
圖上第二個步驟，消息到達服務端後需要存儲到Broker。
大家關注的流量削峯、最終一致性等需求都是需要Broker先存儲下來，然後選擇時機投遞，這才達到流量削峯、泄洪的目的，所以Broker一個非常重要的功能就是存儲。
存儲可以做成很多方式，比如存儲在內存裏，存儲在分佈式KV裏，存儲在磁盤裏，存儲在數據庫裏等等，存儲的選型需要綜合考慮性能/高可用和開發維護成本等諸多因素。
目前主流的方案：追加寫日誌文件（數據部分） + 索引文件的方式，索引設計上可以考慮稠密索引或者稀疏索引，查找消息可以利用跳轉表、二分查找等，還可以通過操作系統的頁緩存、零拷貝等技術來提升磁盤文件的讀寫性能。
3）消費模型
圖上第三個步驟，消息到達Broker後，最終還是需要Consumer去消費消息，這裏就會涉及到消費模型。
這裏的消費模型，目前主要就兩種：單播和廣播。所謂單播，就是點到點；而廣播，是一點對多點。
詳細的單播和廣播消費模型，下面我會圖文詳解。
4）高級特性
圖上第四個步驟，如果Consumer端把消息消費了，除了需要消息確認，還會涉及比如：重複消息、順序消息、消息延遲、事務消息等需要考慮的高級特性。
消息隊列MQ模型
消息隊列MQ主要包含兩種模型：點對點與發佈訂閱兩種模型。
1.點對點模型
1） 角色
點對點模用於 消息生產者 和 消息消費者 之間 點到點 的通信，包含三個角色：
消息隊列（Queue）
發送者(Sender)
接收者(Receiver)
每個消息都被髮送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留着消息，可以放在 內存 中也可以 持久化，直到他們被消費或超時。
2）特點
每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)
發送者和接收者之間在時間上沒有依賴性
接收者在成功接收消息之後需向隊列應答成功
2.發佈訂閱消息模型Topic
1）角色
發佈訂閱模型包含三個角色：
主題（Topic）
發佈者（Publisher）
訂閱者（Subscriber）
多個發佈者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。
2）特點
每個消息可以有多個消費者：和點對點方式不同，發佈消息可以被所有訂閱者消費
發佈者和訂閱者之間有時間上的依賴性。
針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發佈者的消息。
爲了消費消息，訂閱者必須保持運行的狀態。
消息隊列MQ產品選型
1.ActiveMQ
ActiveMQ官網地址：activemq.apache.org
Apache出品，最早使用的消息隊列產品，時間比較長了，最近版本更新比較緩慢，性能在萬級/秒。
2.RabbitMQ
RabbitMQ官網地址：www.rabbitmq.com
RabbitMQ是erlang語言開發，結合erlang語言本身的併發優勢，支持很多的協議：AMQP，XMPP, SMTP, STOMP，性能在萬級/秒，其整體架構圖如下所示：
3.Kafka
Kafka官網地址：kafka.apache.org
Kafka是由Apache軟件基金會開發的一個開源消息系統項目，由Scala寫成。Kafka最初是由LinkedIn開發，並於2011年初開源。Kafka是一個分佈式的、分區的、多複本的日誌提交服務，性能在百萬級/秒，其整體架構圖如下所示：
4.RocketMQ
RocketMQ官網地址：rocketmq.apache.org
阿里開源的消息中間件，純Java開發，具有高吞吐量、高可用性、適合大規模分佈式系統應用的特點，參考Kafka而設計的，性能在十萬級/秒，其整體架構圖如下所示：
5.Pulsar
Pulsar官網地址：pulsar.apache.org
Apache Pulsar是Apache軟件基金會頂級項目，是下一代雲原生分佈式消息流平臺，集消息、存儲、輕量化函數式計算爲一體，採用計算與存儲分離架構設計，支持多租戶、持久化存儲、多機房跨區域數據複製，具有強一致性、高吞吐、低延時及高可擴展性等流數據存儲特性，被看作是雲原生時代實時消息流傳輸、存儲和計算最佳解決方案，其整體架構圖如下所示：
6.消息隊列選型
廣泛來說，電商、金融等對事務性要求很高的，可以考慮RocketMQ，技術挑戰不是特別高，用 RabbitMQ 是不錯的選擇，如果是大數據領域的實時計算、日誌採集等場景可以考慮 Kafka。
----end----
建議收藏備用，如果覺得還行，謝謝【點贊+關注】支持下。
很高興認識你，謝謝關注【mikechen的互聯網架構】，我是【陳睿mikechen】，10+年大廠架構經驗，資深架構師 CTO，曾任職阿里巴巴、淘寶、百度、攜程，專注分享：大廠架構+大廠面經+ 技術管理。
【mikechen的互聯網架構】往期文章推薦：
高併發架構系列：Redis緩存和MySQL數據一致性方案詳解