消息隊列已經逐漸成爲企業應用系統內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能。
當前使用較多的消息隊列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ 等，而部分數據庫如 Redis、MySQL 以及 PhxSQL 也可實現消息隊列的功能。
消息隊列概述
消息隊列是指利用高效可靠的消息傳遞機制進行與平臺無關的數據交流，並基於數據通信來進行分佈式系統的集成。
通過提供消息傳遞和消息排隊模型，它可以在分佈式環境下提供應用解耦、彈性伸縮、冗餘存儲、流量削峯、異步通信、數據同步等等功能，其作爲分佈式系統架構中的一個重要組件，有着舉足輕重的地位。
消息隊列的特點
採用異步處理模式
消息發送者可以發送一個消息而無須等待響應。消息發送者將消息發送到一條虛擬的通道（主題或隊列）上，消息接收者則訂閱或是監聽該通道。
一條信息可能最終轉發給一個或多個消息接收者，這些接收者都無需對消息發送者做出同步迴應。整個過程都是異步的。
應用系統之間解耦合
主要體現在如下兩點：
發送者和接受者不必瞭解對方、只需要確認消息。
發送者和接受者不必同時在線。
比如在線交易系統爲了保證數據的最終一致，在支付系統處理完成後會把支付結果放到消息中間件裏，通知訂單系統修改訂單支付狀態。兩個系統是通過消息中間件解耦的。
消息隊列的傳遞服務模型
消息隊列的傳遞服務模型如下圖所示：
消息隊列的的傳輸模式
點對點模型
點對點模型用於消息生產者和消息消費者之間點到點的通信。消息生產者將消息發送到由某個名字標識的特定消費者。
這個名字實際上對於消費服務中的一個 隊列（ Queue），在消息傳遞給消費者之前它被存儲在這個隊列中。
隊列消息可以放在內存中也可以持久化，以保證在消息服務出現故障時仍然能夠傳遞消息。
傳統的點對點消息中間件通常由消息隊列服務、消息傳遞服務、消息隊列和消息應用程序接口 API 組成。
其典型的結構如下圖所示：
特點如下：
每個消息只用一個消費者。
發送者和接受者沒有時間依賴。
接受者確認消息接受和處理成功。
示意圖如下所示：
發佈/訂閱模型（Pub/Sub）
發佈者/訂閱者模型支持向一個特定的消息主題生產消息。0 或多個訂閱者可能對接收來自特定消息主題的消息感興趣。
在這種模型下，發佈者和訂閱者彼此不知道對方，就好比是匿名公告板。這種模式被概括爲：多個消費者可以獲得消息，在發佈者和訂閱者之間存在時間依賴性。
發佈者需要建立一個訂閱（ Subion），以便消費者能夠訂閱。訂閱者必須保持持續的活動狀態並接收消息。
在這種情況下，在訂閱者未連接時，發佈的消息將在訂閱者重新連接時重新發布，如下圖所示：
特性如下：
每個消息可以有多個訂閱者。
客戶端只有訂閱後才能接收到消息。
注意以下三點：
發佈者和訂閱者有時間依賴：接受者和發佈者只有建立訂閱關係才能收到消息。
持久訂閱：訂閱關係建立後，消息就不會消失，不管訂閱者是否都在線。
非持久訂閱：訂閱者爲了接受消息，必須一直在線。當只有一個訂閱者時約等於點對點模式。
消息隊列應用場景
當你需要使用消息隊列時，首先需要考慮它的必要性。可以使用消息隊列的場景有很多，最常用的幾種，是做應用程序松耦合、異步處理模式、發佈與訂閱、最終一致性、錯峯流控和日誌緩衝等。
反之，如果需要強一致性，關注業務邏輯的處理結果，則使用 RPC 顯得更爲合適。
異步處理
非核心流程異步化，減少系統響應時間，提高吞吐量。例如：短信通知、終端狀態推送、App 推送、用戶註冊等。
消息隊列 一般都內置了高效的通信機制，因此也可以用於單純的消息通訊，比如實現點對點消息隊列或者聊天室等。
應用案例：網站用戶註冊，註冊成功後會過一會發送郵件確認或者短信。
系統解耦
系統之間不是強耦合的，消息接受者可以隨意增加，而不需要修改消息發送者的代碼。
消息發送者的成功不依賴消息接受者（比如：有些銀行接口不穩定，但調用方並不需要依賴這些接口）。
不強依賴於非本系統的核心流程，對於非核心流程，可以放到消息隊列中讓消息消費者去按需消費，而不影響核心主流程。
最終一致性
最終一致性不是消息隊列的必備特性，但確實可以依靠消息隊列來做最終一致性的事情：
先寫消息再操作，確保操作完成後再修改消息狀態。定時任務補償機制實現消息可靠發送接收、業務操作的可靠執行，要注意消息重複與冪等設計。
所有不保證 100% 不丟消息的消息隊列，理論上無法實現最終一致性。
像 Kafka 一類的設計，在設計層面上就有丟消息的可能（比如定時刷盤，如果掉電就會丟消息）。哪怕只丟千分之一的消息，業務也必須用其他的手段來保證結果正確。
廣播
生產者/消費者模式，只需要關心消息是否送達隊列，至於誰希望訂閱和需要消費，是下游的事情，無疑極大地減少了開發和聯調的工作量。
流量削峯和流控
當上下游系統處理能力存在差距的時候，利用消息隊列做一個通用的 “漏斗”，進行限流控制。在下游有能力處理的時候，再進行分發。
舉個例子：用戶在支付系統成功結賬後，訂單系統會通過短信系統向用戶推送扣費通知。
短信系統可能由於短板效應，速度卡在網關上（每秒幾百次請求），跟前端的併發量不是一個數量級。於是，就造成支付系統和短信系統的處理能力出現差異化。
然而用戶晚上個半分鐘左右收到短信，一般是不會有太大問題的。如果沒有消息隊列，兩個系統之間通過協商、滑動窗口等複雜的方案也不是說不能實現。
但系統複雜性指數級增長，勢必在上游或者下游做存儲，並且要處理定時、擁塞等一系列問題。
而且每當有處理能力有差距的時候，都需要單獨開發一套邏輯來維護這套邏輯。
所以，利用中間系統轉儲兩個系統的通信內容，並在下游系統有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。
應用案例：
1） 把消息隊列當成可靠的消息暫存地，進行一定程度的消息堆積。
2）定時進行消息投遞，比如模擬用戶秒殺訪問，進行系統性能壓測。
日誌處理
將消息隊列用在日誌處理中，比如 Kafka 的應用，解決海量日誌傳輸和緩衝的問題。
應用案例：把日誌進行集中收集，用於計算 PV、用戶行爲分析等等。
消息通訊
消息隊列一般都內置了高效的通信機制，因此也可以用於單純的消息通訊，比如實現點對點消息隊列或者聊天室等。
消息隊列的推拉模型
Push 推消息模型
消息生產者將消息發送給消息隊列，消息隊列又將消息推給消息消費者。
Pull 拉消息模型
消費者請求消息隊列接受消息，消息生產者從消息隊列中拉該消息。
兩種類型的區別
兩種類型的區別如下圖：
消息隊列技術對比
本部分主要介紹四種常用的消息隊列（ ActiveMQ/RabbitMQ/RocketMQ/Kafka）的主要特性、優點、缺點。
ActiveMQ
ActiveMQ 是由 Apache 出品， ActiveMQ 是一個完全支持 JMS1.1 和 J2EE1.4 規範的 JMS Provider 實現。
它非常快速，支持多種語言的客戶端和協議，而且可以非常容易的嵌入到企業的應用環境中，並有許多高級功能。
主要特性：
服從 JMS 規範：JMS 規範提供了良好的標準和保證，包括：同步或異步的消息分發，一次和僅一次消息分發，消息接收和訂閱等等。 遵從 JMS 規範的好處在於，不論使用什麼 JMS 實現提供者，這些基礎特性都是可用的。
連接靈活性：ActiveMQ 提供了廣泛的連接協議，支持的協議有：HTTP/S，IP 多播，SSL，TCP，UDP 等等。對衆多協議的支持讓 ActiveMQ 擁有了很好的靈活性。
支持的協議種類多：OpenWire、STOMP、REST、XMPP、AMQP。
持久化插件和安全插件：ActiveMQ 提供了多種持久化選擇。而且， ActiveMQ 的安全性也可以完全依據用戶需求進行自定義鑑權和授權。
支持的客戶端語言種類多：除了 Java 之外，還有 C/C++，.Net，Perl， PHP，Python，Ruby。
代理集羣：多個 ActiveMQ 代理可以組成一個集羣來提供服務。
異常簡單的管理：ActiveMQ 是以開發者思維被設計的。所以，它並不需要專門的管理員，因爲它提供了簡單又實用的管理特性。 有很多種方法可以監控 ActiveMQ 不同層面的數據，包括使用在 JConsole 或者在 ActiveMQ 的 WebConsole 中使用 JMX。 通過處理 JMX 的告警消息，通過使用命令行腳本，甚至可以通過監控各種類型的日誌。
部署環境：ActiveMQ 可以運行在 Java 語言所支持的平臺之上。
使用 ActiveMQ 需要：
JavaJDK
ActiveMQ 安裝包
優點如下：
跨平臺（Java 編寫與平臺無關，ActiveMQ 幾乎可以運行在任何的 JVM上）。
可以用 JDBC：可以將數據持久化到數據庫。雖然使用 JDBC 會降低 ActiveMQ 的性能，但是數據庫一直都是開發人員最熟悉的存儲介質。
支持 JMS 規範：支持 JMS 規範提供的統一接口。
支持自動重連和錯誤重試機制。
有安全機制：支持基於 Shiro，JAAS 等多種安全配置機制，可以對 Queue/Topic 進行認證和授權。
監控完善：擁有完善的監控，包括 WebConsole，JMX，Shell 命令行， Jolokia 的 RESTfulAPI。
界面友善：提供的 WebConsole 可以滿足大部分情況，還有很多第三方的組件可以使用，比如 Hawtio。
缺點如下：
社區活躍度不及 RabbitMQ 高。
根據其他用戶反饋，會出莫名其妙的問題，會丟失消息。
目前重心放到 ActiveMQ 6.0 產品 Apollo，對 5.x 的維護較少。
不適合用於上千個隊列的應用場景。
RabbitMQ
RabbitMQ 於 2007 年發佈，是一個在 AMQP（高級消息隊列協議）基礎上完成的，可複用的企業消息系統，是當前最主流的消息中間件之一。
主要特性如下：
可靠性：提供了多種技術可以讓你在性能和可靠性之間進行權衡。這些技術包括持久性機制、投遞確認、發佈者證實和高可用性機制。
靈活的路由：消息在到達隊列前是通過交換機進行路由的。RabbitMQ 爲典型的路由邏輯提供了多種內置交換機類型。 如果你有更復雜的路由需求，可以將這些交換機組合起來使用，你甚至可以實現自己的交換機類型，並且當做 RabbitMQ 的插件來使用。
消息集羣：在相同局域網中的多個 RabbitMQ 服務器可以聚合在一起，作爲一個獨立的邏輯代理來使用。
隊列高可用：隊列可以在集羣中的機器上進行鏡像，以確保在硬件問題下還保證消息安全。
支持多種協議：支持多種消息隊列協議。
支持多種語言：用 Erlang 語言編寫，支持只要是你能想到的所有編程語言。
管理界面：RabbitMQ 有一個易用的用戶界面，使得用戶可以監控和管理消息 Broker 的許多方面。
跟蹤機制：如果消息異常， RabbitMQ 提供消息跟蹤機制，使用者可以找出發生了什麼。
插件機制：提供了許多插件，來從多方面進行擴展，也可以編寫自己的插件。
部署環境：RabbitMQ 可以運行在 Erlang 語言所支持的平臺之上，包括 Solaris，BSD，Linux，MacOSX，TRU64，Windows 等。
使用 RabbitMQ 需要：
ErLang 語言包
RabbitMQ 安裝包
優點如下：
由於 Erlang 語言的特性，消息隊列性能較好，支持高併發。
健壯、穩定、易用、跨平臺、支持多種語言、文檔齊全。
有消息確認機制和持久化機制，可靠性高。
高度可定製的路由。
管理界面較豐富，在互聯網公司也有較大規模的應用，社區活躍度高。
缺點如下：
儘管結合 Erlang 語言本身的併發優勢，性能較好，但是不利於做二次開發和維護。
實現了代理架構，意味着消息在發送到客戶端之前可以在中央節點上排隊。此特性使得 RabbitMQ 易於使用和部署，但是使得其運行速度較慢，因爲中央節點增加了延遲，消息封裝後也比較大。
需要學習比較複雜的接口和協議，學習和維護成本較高。
RocketMQ
RocketMQ 出自阿里的開源產品，用 Java 語言實現，在設計時參考了 Kafka，並做出了自己的一些改進，消息可靠性上比 Kafka 更好。
RocketMQ 在阿里內部被廣泛應用在訂單，交易，充值，流計算，消息推送，日誌流式處理，Binglog 分發等場景。
主要特性如下：
基於隊列模型：具有高性能、高可靠、高實時、分佈式等特點。
Producer、Consumer 隊列都支持分佈式。
Producer 向一些隊列輪流發送消息，隊列集合稱爲 Topic。Consumer 如果做廣播消費，則一個 Consumer 實例消費這個 Topic 對應的所有隊列。 如果做集羣消費，則多個 Consumer 實例平均消費這個 Topic 對應的隊列集合。
能夠保證嚴格的消息順序。
提供豐富的消息拉取模式。
高效的訂閱者水平擴展能力。
實時的消息訂閱機制。
億級消息堆積能力。
較少的外部依賴。
部署環境：RocketMQ 可以運行在 Java 語言所支持的平臺之上。
使用 RocketMQ 需要：
JavaJDK
安裝 Git、Maven
RocketMQ 安裝包
優點如下：
單機支持 1 萬以上持久化隊列。
RocketMQ 的所有消息都是持久化的，先寫入系統 PAGECACHE，然後刷盤，可以保證內存與磁盤都有一份數據，而訪問時，直接從內存讀取。
模型簡單，接口易用（ JMS 的接口很多場合並不太實用）。
性能非常好，可以允許大量堆積消息在 Broker 中。
支持多種消費模式，包括集羣消費、廣播消費等。
各個環節分佈式擴展設計，支持主從和高可用。
開發度較活躍，版本更新很快。
缺點如下：
支持的客戶端語言不多，目前是 Java 及 C++，其中 C++ 還不成熟。
RocketMQ 社區關注度及成熟度也不及前兩者。
沒有 Web 管理界面，提供了一個 CLI（命令行界面）管理工具帶來查詢、管理和診斷各種問題。
沒有在 MQ 核心裏實現 JMS 等接口。
Kafka
Apache Kafka 是一個分佈式消息發佈訂閱系統。它最初由 LinkedIn 公司基於獨特的設計實現爲一個分佈式的日誌提交系統（a distributed commit log），之後成爲 Apache 項目的一部分。
Kafka 性能高效、可擴展良好並且可持久化。它的分區特性，可複製和可容錯都是不錯的特性。
【加羣】：857565362
主要特性如下：
快速持久化：可以在 O(1) 的系統開銷下進行消息持久化。
高吞吐：在一臺普通的服務器上即可以達到 10W/S 的吞吐速率。
完全的分佈式系統：Broker、Producer 和 Consumer 都原生自動支持分佈式，自動實現負載均衡。
支持同步和異步複製兩種高可用機制。
支持數據批量發送和拉取。
零拷貝技術（zero-copy）：減少 IO 操作步驟，提高系統吞吐量。
數據遷移、擴容對用戶透明。
無需停機即可擴展機器。
其他特性：豐富的消息拉取模型、高效訂閱者水平擴展、實時的消息訂閱、億級的消息堆積能力、定期刪除機制。
部署環境，使用 Kafka 需要：
JavaJDK
Kafka 安裝包
優點如下：
客戶端語言豐富：支持 Java、.Net、PHP、Ruby、Python、Go 等多種語言。
高性能：單機寫入 TPS 約在 100 萬條/秒，消息大小 10 個字節。
提供完全分佈式架構，並有 Replica 機制，擁有較高的可用性和可靠性，理論上支持消息無限堆積。
支持批量操作。
消費者採用 Pull 方式獲取消息。消息有序，通過控制能夠保證所有消息被消費且僅被消費一次。
有優秀的第三方 Kafka Web 管理界面 Kafka-Manager。
在日誌領域比較成熟，被多家公司和多個開源項目使用。
缺點如下：
Kafka 單機超過 64 個隊列/分區時， Load 時會發生明顯的飆高現象。隊列越多，負載越高，發送消息響應時間變長。
使用短輪詢方式，實時性取決於輪詢間隔時間。
消費失敗不支持重試。
支持消息順序，但是一臺代理宕機後，就會產生消息亂序。
社區更新較慢。
幾種消息隊列對比
這裏列舉了上述四種消息隊列的差異對比：
Kafka 在於分佈式架構，RabbitMQ 基於 AMQP 協議來實現，RocketMQ 的思路來源於 Kafka，改成了主從結構，在事務性和可靠性方面做了優化。廣泛來說，電商、金融等對事務一致性要求很高的，可以考慮 RabbitMQ 和 RocketMQ，對性能要求高的可考慮 Kafka。
我這兒整理了比較全面的JAVA相關的面試資料，
需要領取面試資料的同學，請加羣：473984645
獲取更多學習資料，可以加羣：473984645或掃描下方二維碼
