淺談消息隊(duì)列及常見(jiàn)的消息中間件

前言

消息隊(duì)列 已經(jīng)逐漸成為企業(yè)應(yīng)用系統(tǒng) 內(nèi)部通信 的核心手段宣蔚。它具有 低耦合、可靠投遞寒跳、廣播、流量控制峡继、最終一致性 等一系列功能。

當(dāng)前使用較多的 消息隊(duì)列 有 RabbitMQ匈挖、RocketMQ碾牌、ActiveMQ、Kafka儡循、ZeroMQ舶吗、MetaMQ 等，而部分數(shù)據(jù)庫(kù) 如 Redis择膝、MySQL 以及 phxsql 也可實(shí)現(xiàn)消息隊(duì)列的功能誓琼。

1. 消息隊(duì)列概述

消息隊(duì)列 是指利用 高效可靠 的 消息傳遞機(jī)制 進(jìn)行與平臺(tái)無(wú)關(guān)的 數(shù)據(jù)交流，并基于數(shù)據(jù)通信來(lái)進(jìn)行分布式系統(tǒng)的集成肴捉。

通過(guò)提供 消息傳遞 和 消息排隊(duì) 模型腹侣，它可以在 分布式環(huán)境 下提供 應(yīng)用解耦、彈性伸縮齿穗、冗余存儲(chǔ)傲隶、流量削峰、異步通信窃页、數(shù)據(jù)同步 等等功能跺株，其作為 分布式系統(tǒng)架構(gòu) 中的一個(gè)重要組件复濒，有著舉足輕重的地位。

2. 消息隊(duì)列的特點(diǎn)

2.1. 采用異步處理模式

消息發(fā)送者 可以發(fā)送一個(gè)消息而無(wú)須等待響應(yīng)乒省。消息發(fā)送者 將消息發(fā)送到一條 虛擬的通道（主題 或 隊(duì)列）上巧颈，消息接收者 則 訂閱 或是 監(jiān)聽(tīng) 該通道。一條信息可能最終轉(zhuǎn)發(fā)給 一個(gè)或多個(gè) 消息接收者袖扛，這些接收者都無(wú)需對(duì) 消息發(fā)送者 做出 同步回應(yīng)砸泛。整個(gè)過(guò)程都是 異步的。

2.2. 應(yīng)用系統(tǒng)之間解耦合

主要體現(xiàn)在如下兩點(diǎn)：

1. 發(fā)送者和接受者不必了解對(duì)方攻锰、只需要 確認(rèn)消息晾嘶；
2. 發(fā)送者和接受者 不必同時(shí)在線。

比如在線交易系統(tǒng)為了保證數(shù)據(jù)的 最終一致娶吞，在 支付系統(tǒng) 處理完成后會(huì)把 支付結(jié)果 放到 消息中間件 里垒迂，通知 訂單系統(tǒng) 修改 訂單支付狀態(tài)。兩個(gè)系統(tǒng)是通過(guò)消息中間件解耦的妒蛇。

3. 消息隊(duì)列的傳遞服務(wù)模型

消息隊(duì)列的 傳遞服務(wù)模型 如下圖所示：

4. 消息隊(duì)列的的傳輸模式

4.1. 點(diǎn)對(duì)點(diǎn)模型

點(diǎn)對(duì)點(diǎn)模型 用于 消息生產(chǎn)者 和 消息消費(fèi)者 之間 點(diǎn)到點(diǎn) 的通信机断。消息生產(chǎn)者將消息發(fā)送到由某個(gè)名字標(biāo)識(shí)的特定消費(fèi)者。這個(gè)名字實(shí)際上對(duì)應(yīng)消費(fèi)服務(wù)中的一個(gè) 隊(duì)列（Queue）绣夺，在消息傳遞給消費(fèi)者之前它被 存儲(chǔ) 在這個(gè)隊(duì)列中吏奸。隊(duì)列消息 可以放在 內(nèi)存 中也可以 持久化，以保證在消息服務(wù)出現(xiàn)故障時(shí)仍然能夠傳遞消息陶耍。

傳統(tǒng)的點(diǎn)對(duì)點(diǎn)消息中間件通常由 消息隊(duì)列服務(wù)奋蔚、消息傳遞服務(wù)、消息隊(duì)列 和 消息應(yīng)用程序接口 API 組成烈钞，其典型的結(jié)構(gòu)如下圖所示泊碑。

特點(diǎn)：

1. 每個(gè)消息只用一個(gè)消費(fèi)者；
2. 發(fā)送者和接受者沒(méi)有時(shí)間依賴毯欣；
3. 接受者確認(rèn)消息接受和處理成功馒过。

示意圖如下所示：

4.2. 發(fā)布/訂閱模型（Pub/Sub）

發(fā)布者/訂閱者 模型支持向一個(gè)特定的 消息主題 生產(chǎn)消息。0 或 多個(gè)訂閱者 可能對(duì)接收來(lái)自 特定消息主題 的消息感興趣酗钞。

在這種模型下腹忽，發(fā)布者和訂閱者彼此不知道對(duì)方，就好比是匿名公告板砚作。這種模式被概況為：多個(gè)消費(fèi)者可以獲得消息窘奏，在 發(fā)布者 和 訂閱者 之間存在 時(shí)間依賴性。發(fā)布者需要建立一個(gè) 訂閱（subscription）葫录，以便能夠消費(fèi)者訂閱蔼夜。訂閱者 必須保持 持續(xù)的活動(dòng)狀態(tài) 并 接收消息。

在這種情況下压昼，在訂閱者 未連接時(shí)求冷，發(fā)布的消息將在訂閱者 重新連接 時(shí) 重新發(fā)布瘤运，如下圖所示：

特性：

1. 每個(gè)消息可以有多個(gè)訂閱者；
2. 客戶端只有訂閱后才能接收到消息匠题；
3. 持久訂閱和非持久訂閱拯坟。

注意：

1. 發(fā)布者和訂閱者有時(shí)間依賴：接受者和發(fā)布者只有建立訂閱關(guān)系才能收到消息；
2. 持久訂閱：訂閱關(guān)系建立后韭山，消息就不會(huì)消失郁季，不管訂閱者是否都在線；
3. 非持久訂閱：訂閱者為了接受消息钱磅，必須一直在線梦裂。 當(dāng)只有一個(gè)訂閱者時(shí)約等于點(diǎn)對(duì)點(diǎn)模式

5. 消息隊(duì)列應(yīng)用場(chǎng)景

當(dāng)你需要使用 消息隊(duì)列 時(shí)，首先需要考慮它的必要性盖淡∧昴可以使用消息隊(duì)列的場(chǎng)景有很多，最常用的幾種褪迟，是做 應(yīng)用程序松耦合冗恨、異步處理模式、發(fā)布與訂閱味赃、最終一致性掀抹、錯(cuò)峰流控 和 日志緩沖 等。反之心俗，如果需要 強(qiáng)一致性傲武，關(guān)注業(yè)務(wù)邏輯的處理結(jié)果，則使用 RPC 顯得更為合適城榛。

5.1. 異步處理

非核心 流程 異步化揪利，減少系統(tǒng) 響應(yīng)時(shí)間，提高 吞吐量吠谢。例如：短信通知土童、終端狀態(tài)推送诗茎、App 推送工坊、用戶注冊(cè) 等。

消息隊(duì)列 一般都內(nèi)置了 高效的通信機(jī)制敢订，因此也可以用于單純的消息通訊王污，比如實(shí)現(xiàn) 點(diǎn)對(duì)點(diǎn)消息隊(duì)列 或者 聊天室 等误债。

應(yīng)用案例

網(wǎng)站用戶注冊(cè)郊供，注冊(cè)成功后會(huì)過(guò)一會(huì)發(fā)送郵件確認(rèn)或者短息。

5.2. 系統(tǒng)解耦

• 系統(tǒng)之間不是 強(qiáng)耦合的诀豁，消息接受者 可以隨意增加矾柜，而不需要修改 消息發(fā)送者的代碼阱驾。消息發(fā)送者 的成功不依賴 消息接受者（比如：有些銀行接口不穩(wěn)定就谜，但調(diào)用方并不需要依賴這些接口）。
• 不強(qiáng)依賴 于非本系統(tǒng)的核心流程里覆，對(duì)于 非核心流程丧荐，可以放到消息隊(duì)列中讓 消息消費(fèi)者 去按需消費(fèi)，而 不影響核心主流程喧枷。

5.3. 最終一致性

最終一致性 不是 消息隊(duì)列 的必備特性虹统，但確實(shí)可以依靠 消息隊(duì)列 來(lái)做 最終一致性 的事情。

• 先寫(xiě)消息再操作隧甚，確保操作完成后再修改消息狀態(tài)车荔。定時(shí)任務(wù)補(bǔ)償機(jī)制 實(shí)現(xiàn)消息 可靠發(fā)送接收、業(yè)務(wù)操作的可靠執(zhí)行戚扳，要注意 消息重復(fù) 與 冪等設(shè)計(jì)忧便。
• 所有不保證 100% 不丟消息 的消息隊(duì)列，理論上無(wú)法實(shí)現(xiàn) 最終一致性咖城。

像 Kafka 一類的設(shè)計(jì)茬腿，在設(shè)計(jì)層面上就有 丟消息 的可能（比如 定時(shí)刷盤(pán)，如果掉電就會(huì)丟消息）宜雀。哪怕只丟千分之一的消息切平，業(yè)務(wù)也必須用其他的手段來(lái)保證結(jié)果正確。

5.4. 廣播

生產(chǎn)者/消費(fèi)者 模式辐董，只需要關(guān)心消息是否 送達(dá)隊(duì)列悴品，至于誰(shuí)希望訂閱和需要消費(fèi)，是 下游 的事情简烘，無(wú)疑極大地減少了開(kāi)發(fā)和聯(lián)調(diào)的工作量苔严。

5.5. 流量削峰和流控

當(dāng) 上下游系統(tǒng) 處理能力存在差距的時(shí)候，利用 消息隊(duì)列 做一個(gè)通用的 “漏斗”孤澎，進(jìn)行 限流控制届氢。在下游有能力處理的時(shí)候，再進(jìn)行分發(fā)覆旭。

舉個(gè)例子：用戶在支付系統(tǒng)成功結(jié)賬后退子，訂單系統(tǒng)會(huì)通過(guò)短信系統(tǒng)向用戶推送扣費(fèi)通知。 短信系統(tǒng) 可能由于 短板效應(yīng)型将，速度卡在 網(wǎng)關(guān) 上（每秒幾百次請(qǐng)求）寂祥，跟 前端的并發(fā)量 不是一個(gè)數(shù)量級(jí)。 于是七兜，就造成 支付系統(tǒng) 和 短信系統(tǒng) 的處理能力出現(xiàn)差異化丸凭。

然而用戶晚上個(gè)半分鐘左右收到短信，一般是不會(huì)有太大問(wèn)題的。如果沒(méi)有消息隊(duì)列惜犀，兩個(gè)系統(tǒng)之間通過(guò) 協(xié)商铛碑、滑動(dòng)窗口 等復(fù)雜的方案也不是說(shuō)不能實(shí)現(xiàn)。但 系統(tǒng)復(fù)雜性 指數(shù)級(jí)增長(zhǎng)虽界，勢(shì)必在 上游 或者 下游 做 存儲(chǔ)亚茬，并且要處理 定時(shí)、擁塞 等一系列問(wèn)題浓恳。而且每當(dāng)有 處理能力有差距 的時(shí)候刹缝，都需要 單獨(dú) 開(kāi)發(fā)一套邏輯來(lái)維護(hù)這套邏輯。

所以颈将，利用中間系統(tǒng)轉(zhuǎn)儲(chǔ)兩個(gè)系統(tǒng)的通信內(nèi)容梢夯，并在下游系統(tǒng)有能力處理這些消息的時(shí)候，再處理這些消息晴圾，是一套相對(duì)較通用的方式颂砸。

應(yīng)用案例

1. 把消息隊(duì)列當(dāng)成可靠的 消息暫存地，進(jìn)行一定程度的 消息堆積死姚；
2. 定時(shí)進(jìn)行消息投遞人乓，比如模擬 用戶秒殺 訪問(wèn)，進(jìn)行 系統(tǒng)性能壓測(cè)都毒。

5.6. 日志處理

將消息隊(duì)列用在 日志處理 中色罚，比如 Kafka 的應(yīng)用，解決 海量日志 傳輸和緩沖的問(wèn)題账劲。

應(yīng)用案例

把日志進(jìn)行集中收集戳护，用于計(jì)算 PV、用戶行為分析 等等瀑焦。

5.7. 消息通訊

消息隊(duì)列一般都內(nèi)置了 高效的通信機(jī)制腌且，因此也可以用于單純的 消息通訊，比如實(shí)現(xiàn) 點(diǎn)對(duì)點(diǎn)消息隊(duì)列 或者 聊天室 等榛瓮。

6. 消息隊(duì)列的推拉模型

6.1. Push推消息模型

消息生產(chǎn)者 將消息發(fā)送給 消息隊(duì)列铺董，消息隊(duì)列 又將消息推給 消息消費(fèi)者。

6.2. Pull拉消息模型

消費(fèi)者 請(qǐng)求 消息隊(duì)列 接受消息禀晓，消息生產(chǎn)者 從 消息隊(duì)列 中拉該消息精续。

6.3. 兩種類型的區(qū)別

7. 消息隊(duì)列技術(shù)對(duì)比

本部分主要介紹四種常用的消息隊(duì)列（ActiveMQ / RabbitMQ / RocketMQ / Kafka）的主要特性、優(yōu)點(diǎn)匆绣、缺點(diǎn)驻右。

7.1. ActiveMQ

ActiveMQ 是由 Apache 出品什黑，ActiveMQ 是一個(gè)完全支持JMS1.1 和 J2EE 1.4 規(guī)范的 JMS Provider 實(shí)現(xiàn)崎淳。它非常快速愕把，支持 多種語(yǔ)言的客戶端 和 協(xié)議拣凹，而且可以非常容易的嵌入到企業(yè)的應(yīng)用環(huán)境中森爽，并有許多高級(jí)功能。

(a) 主要特性

1. 服從JMS規(guī)范：JMS 規(guī)范提供了良好的標(biāo)準(zhǔn)和保證嚣镜，包括：同步 或 異步 的消息分發(fā)爬迟，一次和僅一次的消息分發(fā)，消息接收 和 訂閱 等等菊匿。遵從 JMS 規(guī)范的好處在于付呕，不論使用什么 JMS 實(shí)現(xiàn)提供者，這些基礎(chǔ)特性都是可用的跌捆；
2. 連接靈活性：ActiveMQ 提供了廣泛的 連接協(xié)議徽职，支持的協(xié)議有：HTTP/S，IP 多播佩厚，SSL姆钉，TCP，UDP 等等抄瓦。對(duì)眾多協(xié)議的支持讓 ActiveMQ 擁有了很好的靈活性潮瓶；
3. 支持的協(xié)議種類多：OpenWire、STOMP钙姊、REST毯辅、XMPP、AMQP煞额；
4. 持久化插件和安全插件：ActiveMQ 提供了 多種持久化 選擇悉罕。而且，ActiveMQ 的安全性也可以完全依據(jù)用戶需求進(jìn)行 自定義鑒權(quán) 和 授權(quán)立镶；
5. 支持的客戶端語(yǔ)言種類多：除了 Java 之外壁袄，還有：C/C++，.NET媚媒，Perl嗜逻，PHP，Python缭召，Ruby栈顷；
6. 代理集群：多個(gè) ActiveMQ 代理 可以組成一個(gè) 集群 來(lái)提供服務(wù)；
7. 異常簡(jiǎn)單的管理：ActiveMQ 是以開(kāi)發(fā)者思維被設(shè)計(jì)的嵌巷。所以萄凤，它并不需要專門(mén)的管理員，因?yàn)樗峁┝撕?jiǎn)單又使用的管理特性搪哪。有很多中方法可以 監(jiān)控 ActiveMQ 不同層面的數(shù)據(jù)靡努，包括使用在 JConsole 或者在 ActiveMQ 的 Web Console 中使用 JMX。通過(guò)處理 JMX 的告警消息，通過(guò)使用 命令行腳本惑朦，甚至可以通過(guò)監(jiān)控各種類型的 日志兽泄。

(b) 部署環(huán)境

ActiveMQ 可以運(yùn)行在 Java 語(yǔ)言所支持的平臺(tái)之上。使用 ActiveMQ 需要：

• Java JDK
• ActiveMQ 安裝包

(c) 優(yōu)點(diǎn)

1. 跨平臺(tái) (JAVA 編寫(xiě)與平臺(tái)無(wú)關(guān)漾月，ActiveMQ 幾乎可以運(yùn)行在任何的 JVM 上)病梢；
2. 可以用 JDBC：可以將 數(shù)據(jù)持久化 到數(shù)據(jù)庫(kù)。雖然使用 JDBC 會(huì)降低 ActiveMQ 的性能梁肿，但是數(shù)據(jù)庫(kù)一直都是開(kāi)發(fā)人員最熟悉的存儲(chǔ)介質(zhì)蜓陌；
3. 支持 JMS 規(guī)范：支持 JMS 規(guī)范提供的 統(tǒng)一接口;
4. 支持 自動(dòng)重連 和 錯(cuò)誤重試機(jī)制；
5. 有安全機(jī)制：支持基于 shiro吩蔑，jaas 等多種 安全配置機(jī)制护奈，可以對(duì) Queue/Topic 進(jìn)行 認(rèn)證和授權(quán)；
6. 監(jiān)控完善：擁有完善的 監(jiān)控哥纫，包括 Web Console霉旗，JMX，Shell 命令行蛀骇，Jolokia 的 RESTful API厌秒；
7. 界面友善：提供的 Web Console 可以滿足大部分情況，還有很多 第三方的組件 可以使用擅憔，比如 hawtio鸵闪；

(d) 缺點(diǎn)

1. 社區(qū)活躍度不及 RabbitMQ 高；
2. 根據(jù)其他用戶反饋暑诸，會(huì)出莫名其妙的問(wèn)題蚌讼，會(huì) 丟失消息；
3. 目前重心放到 activemq 6.0 產(chǎn)品 Apollo个榕，對(duì) 5.x 的維護(hù)較少篡石；
4. 不適合用于 上千個(gè)隊(duì)列 的應(yīng)用場(chǎng)景；

7.2. RabbitMQ

RabbitMQ 于 2007 年發(fā)布西采，是一個(gè)在 AMQP (高級(jí)消息隊(duì)列協(xié)議)基礎(chǔ)上完成的凰萨，可復(fù)用的企業(yè)消息系統(tǒng)，是當(dāng)前最主流的消息中間件之一械馆。

(a) 主要特性

1. 可靠性：提供了多種技術(shù)可以讓你在 性能 和 可靠性 之間進(jìn)行 權(quán)衡胖眷。這些技術(shù)包括 持久性機(jī)制、投遞確認(rèn)霹崎、發(fā)布者證實(shí) 和 高可用性機(jī)制珊搀；
2. 靈活的路由：消息在到達(dá)隊(duì)列前是通過(guò) 交換機(jī) 進(jìn)行 路由 的。RabbitMQ 為典型的路由邏輯提供了 多種內(nèi)置交換機(jī) 類型尾菇。如果你有更復(fù)雜的路由需求境析，可以將這些交換機(jī)組合起來(lái)使用囚枪，你甚至可以實(shí)現(xiàn)自己的交換機(jī)類型，并且當(dāng)做 RabbitMQ 的 插件 來(lái)使用簿晓；
3. 消息集群：在相同局域網(wǎng)中的多個(gè) RabbitMQ 服務(wù)器可以 聚合 在一起，作為一個(gè)獨(dú)立的邏輯代理來(lái)使用千埃；
4. 隊(duì)列高可用：隊(duì)列可以在集群中的機(jī)器上 進(jìn)行鏡像憔儿，以確保在硬件問(wèn)題下還保證 消息安全；
5. 支持多種協(xié)議：支持 多種消息隊(duì)列協(xié)議放可；
6. 支持多種語(yǔ)言：用 Erlang 語(yǔ)言編寫(xiě)谒臼，支持只要是你能想到的 所有編程語(yǔ)言；
7. 管理界面： RabbitMQ 有一個(gè)易用的 用戶界面耀里，使得用戶可以 監(jiān)控 和 管理 消息 Broker 的許多方面蜈缤；
8. 跟蹤機(jī)制：如果 消息異常，RabbitMQ 提供消息跟蹤機(jī)制冯挎，使用者可以找出發(fā)生了什么底哥；
9. 插件機(jī)制：提供了許多 插件，來(lái)從多方面進(jìn)行擴(kuò)展房官，也可以編寫(xiě)自己的插件趾徽。

(b) 部署環(huán)境

RabbitMQ 可以運(yùn)行在 Erlang 語(yǔ)言所支持的平臺(tái)之上，包括 Solaris翰守，BSD孵奶，Linux，MacOSX蜡峰，TRU64了袁，Windows 等。使用 RabbitMQ 需要：

• ErLang 語(yǔ)言包
• RabbitMQ 安裝包

(c) 優(yōu)點(diǎn)

1. 由于 Erlang 語(yǔ)言的特性湿颅，消息隊(duì)列性能較好载绿，支持 高并發(fā)；
2. 健壯油航、穩(wěn)定卢鹦、易用、跨平臺(tái)劝堪、支持 多種語(yǔ)言冀自、文檔齊全；
3. 有消息 確認(rèn)機(jī)制 和 持久化機(jī)制秒啦，可靠性高熬粗；
4. 高度可定制的 路由；
5. 管理界面 較豐富余境，在互聯(lián)網(wǎng)公司也有較大規(guī)模的應(yīng)用驻呐，社區(qū)活躍度高灌诅。

(d) 缺點(diǎn)

1. 盡管結(jié)合 Erlang 語(yǔ)言本身的并發(fā)優(yōu)勢(shì)，性能較好含末，但是不利于做 二次開(kāi)發(fā)和維護(hù)猜拾；
2. 實(shí)現(xiàn)了 代理架構(gòu)，意味著消息在發(fā)送到客戶端之前可以在 中央節(jié)點(diǎn) 上排隊(duì)佣盒。此特性使得 RabbitMQ 易于使用和部署挎袜，但是使得其 運(yùn)行速度較慢，因?yàn)橹醒牍?jié)點(diǎn) 增加了延遲肥惭，消息封裝后 也比較大盯仪；
3. 需要學(xué)習(xí) 比較復(fù)雜 的 接口和協(xié)議，學(xué)習(xí)和維護(hù)成本較高蜜葱。

7.3. RocketMQ

RocketMQ 出自 阿里 的開(kāi)源產(chǎn)品全景，用 Java 語(yǔ)言實(shí)現(xiàn)，在設(shè)計(jì)時(shí)參考了 Kafka牵囤，并做出了自己的一些改進(jìn)爸黄，消息可靠性上 比 Kafka 更好。RocketMQ 在阿里內(nèi)部被廣泛應(yīng)用在 訂單揭鳞，交易馆纳，充值，流計(jì)算汹桦，消息推送鲁驶，日志流式處理，binglog 分發(fā) 等場(chǎng)景舞骆。

(a) 主要特性

1. 基于 隊(duì)列模型：具有 高性能钥弯、高可靠、高實(shí)時(shí)督禽、分布式 等特點(diǎn)脆霎；
2. Producer、Consumer狈惫、隊(duì)列 都支持 分布式睛蛛；
3. Producer 向一些隊(duì)列輪流發(fā)送消息，隊(duì)列集合 稱為 Topic胧谈。Consumer 如果做 廣播消費(fèi)忆肾，則一個(gè) Consumer 實(shí)例消費(fèi)這個(gè) Topic 對(duì)應(yīng)的 所有隊(duì)列；如果做 集群消費(fèi)菱肖，則 多個(gè) Consumer 實(shí)例 平均消費(fèi) 這個(gè) Topic 對(duì)應(yīng)的隊(duì)列集合客冈；
4. 能夠保證 嚴(yán)格的消息順序；
5. 提供豐富的 消息拉取模式稳强；
6. 高效的訂閱者 水平擴(kuò)展能力场仲；
7. 實(shí)時(shí) 的 消息訂閱機(jī)制和悦；
8. 億級(jí) 消息堆積 能力；
9. 較少的外部依賴渠缕。

(b) 部署環(huán)境

RocketMQ 可以運(yùn)行在 Java 語(yǔ)言所支持的平臺(tái)之上鸽素。使用 RocketMQ 需要：

• Java JDK
• 安裝 git、Maven
• RocketMQ 安裝包

(c) 優(yōu)點(diǎn)

1. 單機(jī) 支持 1 萬(wàn)以上 持久化隊(duì)列亦鳞；
2. RocketMQ 的所有消息都是 持久化的馍忽，先寫(xiě)入系統(tǒng) PAGECACHE，然后 刷盤(pán)蚜迅，可以保證 內(nèi)存 與 磁盤(pán) 都有一份數(shù)據(jù)舵匾，而 訪問(wèn) 時(shí)俊抵，直接 從內(nèi)存讀取谁不。
3. 模型簡(jiǎn)單，接口易用（JMS 的接口很多場(chǎng)合并不太實(shí)用）徽诲；
4. 性能非常好刹帕，可以允許 大量堆積消息 在 Broker 中；
5. 支持 多種消費(fèi)模式谎替，包括 集群消費(fèi)偷溺、廣播消費(fèi)等；
6. 各個(gè)環(huán)節(jié) 分布式擴(kuò)展設(shè)計(jì)钱贯，支持 主從 和 高可用挫掏；
7. 開(kāi)發(fā)度較活躍，版本更新很快秩命。

(d) 缺點(diǎn)

1. 支持的 客戶端語(yǔ)言 不多尉共，目前是 Java 及 C++，其中 C++ 還不成熟弃锐；
2. RocketMQ 社區(qū)關(guān)注度及成熟度也不及前兩者袄友；
3. 沒(méi)有 Web 管理界面，提供了一個(gè) CLI (命令行界面) 管理工具帶來(lái) 查詢霹菊、管理 和 診斷各種問(wèn)題剧蚣；
4. 沒(méi)有在 MQ 核心里實(shí)現(xiàn) JMS 等接口；

7.4. Kafka

Apache Kafka 是一個(gè) 分布式消息發(fā)布訂閱 系統(tǒng)旋廷。它最初由 LinkedIn 公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個(gè) 分布式的日志提交系統(tǒng) (a distributed commit log)鸠按，之后成為 Apache 項(xiàng)目的一部分。Kafka 性能高效饶碘、可擴(kuò)展良好 并且 可持久化待诅。它的 分區(qū)特性，可復(fù)制 和 可容錯(cuò) 都是其不錯(cuò)的特性熊镣。

(a) 主要特性

1. 快速持久化：可以在 O(1) 的系統(tǒng)開(kāi)銷(xiāo)下進(jìn)行 消息持久化卑雁；
2. 高吞吐：在一臺(tái)普通的服務(wù)器上既可以達(dá)到 10W/s 的 吞吐速率募书；
3. 完全的分布式系統(tǒng)：Broker、Producer 和 Consumer 都原生自動(dòng)支持 分布式测蹲，自動(dòng)實(shí)現(xiàn) 負(fù)載均衡莹捡；
4. 支持 同步 和 異步 復(fù)制兩種 高可用機(jī)制；
5. 支持 數(shù)據(jù)批量發(fā)送 和 拉取扣甲；
6. 零拷貝技術(shù)(zero-copy)：減少 IO 操作步驟篮赢，提高 系統(tǒng)吞吐量；
7. 數(shù)據(jù)遷移琉挖、擴(kuò)容 對(duì)用戶透明启泣；
8. 無(wú)需停機(jī) 即可擴(kuò)展機(jī)器；
9. 其他特性：豐富的 消息拉取模型示辈、高效 訂閱者水平擴(kuò)展寥茫、實(shí)時(shí)的 消息訂閱、億級(jí)的 消息堆積能力矾麻、定期刪除機(jī)制纱耻；

(b) 部署環(huán)境

使用 Kafka 需要：

• Java JDK
• Kafka 安裝包

(c) 優(yōu)點(diǎn)

1. 客戶端語(yǔ)言豐富：支持 Java、.Net险耀、PHP弄喘、Ruby、Python甩牺、Go 等多種語(yǔ)言蘑志；
2. 高性能：?jiǎn)螜C(jī)寫(xiě)入 TPS 約在 100 萬(wàn)條/秒，消息大小 10 個(gè)字節(jié)贬派；
3. 提供 完全分布式架構(gòu)急但，并有 replica 機(jī)制，擁有較高的 可用性 和 可靠性赠群，理論上支持 消息無(wú)限堆積羊始；
4. 支持批量操作；
5. 消費(fèi)者 采用 Pull 方式獲取消息查描。消息有序突委，通過(guò)控制 能夠保證所有消息被消費(fèi)且僅被消費(fèi) 一次；
6. 有優(yōu)秀的第三方 Kafka Web 管理界面 Kafka-Manager冬三；
7. 在 日志領(lǐng)域 比較成熟匀油，被多家公司和多個(gè)開(kāi)源項(xiàng)目使用。

(d) 缺點(diǎn)

1. Kafka 單機(jī)超過(guò) 64 個(gè) 隊(duì)列/分區(qū) 時(shí)勾笆，Load 時(shí)會(huì)發(fā)生明顯的飆高現(xiàn)象敌蚜。隊(duì)列 越多，負(fù)載 越高窝爪，發(fā)送消息 響應(yīng)時(shí)間變長(zhǎng)弛车；
2. 使用 短輪詢方式齐媒，實(shí)時(shí)性 取決于 輪詢間隔時(shí)間；
3. 消費(fèi)失敗 不支持重試纷跛；
4. 支持 消息順序喻括，但是 一臺(tái)代理宕機(jī) 后，就會(huì)產(chǎn)生 消息亂序贫奠；
5. 社區(qū)更新較慢唬血。

7.5. 幾種消息隊(duì)列對(duì)比

這里列舉了上述四種消息隊(duì)列的差異對(duì)比：

Kafka 在于 分布式架構(gòu)，RabbitMQ 基于 AMQP 協(xié)議 來(lái)實(shí)現(xiàn)魁淳，RocketMQ 的思路來(lái)源于 Kafka飘诗，改成了 主從結(jié)構(gòu)，在 事務(wù)性 和 可靠性 方面做了優(yōu)化界逛。廣泛來(lái)說(shuō)昆稿，電商、金融 等對(duì) 事務(wù)一致性 要求很高的息拜，可以考慮 RabbitMQ 和 RocketMQ溉潭，對(duì) 性能要求高 的可考慮 Kafka。

本文由mdnice多平臺(tái)發(fā)布