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

[[276519]]

圖片來自 Pexels

當(dāng)前使用較多的消息隊(duì)列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ 等，而部分?jǐn)?shù)據(jù)庫如 Redis、MySQL 以及 PhxSQL 也可實(shí)現(xiàn)消息隊(duì)列的功能。

[[276520]]

消息隊(duì)列概述

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

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

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

采用異步處理模式

消息發(fā)送者可以發(fā)送一個(gè)消息而無須等待響應(yīng)。消息發(fā)送者將消息發(fā)送到一條虛擬的通道(主題或隊(duì)列)上，消息接收者則訂閱或是監(jiān)聽該通道。

一條信息可能最終轉(zhuǎn)發(fā)給一個(gè)或多個(gè)消息接收者，這些接收者都無需對(duì)消息發(fā)送者做出同步回應(yīng)。整個(gè)過程都是異步的。

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

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

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

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

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

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

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

點(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ì)于消費(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)如下：

• 每個(gè)消息只用一個(gè)消費(fèi)者。
• 發(fā)送者和接受者沒有時(shí)間依賴。
• 接受者確認(rèn)消息接受和處理成功。

示意圖如下所示：

發(fā)布/訂閱模型(Pub/Sub)

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

在這種模型下，發(fā)布者和訂閱者彼此不知道對(duì)方，就好比是匿名公告板。這種模式被概括為：多個(gè)消費(fèi)者可以獲得消息，在發(fā)布者和訂閱者之間存在時(shí)間依賴性。

發(fā)布者需要建立一個(gè)訂閱( Subscription)，以便消費(fèi)者能夠訂閱。訂閱者必須保持持續(xù)的活動(dòng)狀態(tài)并接收消息。

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

特性如下：

• 每個(gè)消息可以有多個(gè)訂閱者。
• 客戶端只有訂閱后才能接收到消息。
• 持久訂閱和非持久訂閱。

注意以下三點(diǎn)：

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

消息隊(duì)列應(yīng)用場景

當(dāng)你需要使用消息隊(duì)列時(shí)，首先需要考慮它的必要性?？梢允褂孟㈥?duì)列的場景有很多，最常用的幾種，是做應(yīng)用程序松耦合、異步處理模式、發(fā)布與訂閱、最終一致性、錯(cuò)峰流控和日志緩沖等。

反之，如果需要強(qiáng)一致性，關(guān)注業(yè)務(wù)邏輯的處理結(jié)果，則使用 RPC 顯得更為合適。

異步處理

非核心流程異步化，減少系統(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ì)過一會(huì)發(fā)送郵件確認(rèn)或者短信。

系統(tǒng)解耦

系統(tǒng)之間不是強(qiáng)耦合的，消息接受者可以隨意增加，而不需要修改消息發(fā)送者的代碼。

消息發(fā)送者的成功不依賴消息接受者(比如：有些銀行接口不穩(wěn)定，但調(diào)用方并不需要依賴這些接口)。

不強(qiáng)依賴于非本系統(tǒng)的核心流程，對(duì)于非核心流程，可以放到消息隊(duì)列中讓消息消費(fèi)者去按需消費(fèi)，而不影響核心主流程。

最終一致性

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

先寫消息再操作，確保操作完成后再修改消息狀態(tài)。定時(shí)任務(wù)補(bǔ)償機(jī)制實(shí)現(xiàn)消息可靠發(fā)送接收、業(yè)務(wù)操作的可靠執(zhí)行，要注意消息重復(fù)與冪等設(shè)計(jì)。

所有不保證 100% 不丟消息的消息隊(duì)列，理論上無法實(shí)現(xiàn)最終一致性。

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

廣播

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

流量削峰和流控

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

舉個(gè)例子：用戶在支付系統(tǒng)成功結(jié)賬后，訂單系統(tǒng)會(huì)通過短信系統(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ì)有太大問題的。如果沒有消息隊(duì)列，兩個(gè)系統(tǒng)之間通過協(xié)商、滑動(dòng)窗口等復(fù)雜的方案也不是說不能實(shí)現(xiàn)。

但系統(tǒng)復(fù)雜性指數(shù)級(jí)增長，勢(shì)必在上游或者下游做存儲(chǔ)，并且要處理定時(shí)、擁塞等一系列問題。

而且每當(dāng)有處理能力有差距的時(shí)候，都需要單獨(dú)開發(fā)一套邏輯來維護(hù)這套邏輯。

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

應(yīng)用案例：

• 把消息隊(duì)列當(dāng)成可靠的消息暫存地，進(jìn)行一定程度的消息堆積。
• 定時(shí)進(jìn)行消息投遞，比如模擬用戶秒殺訪問，進(jìn)行系統(tǒng)性能壓測。

日志處理

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

應(yīng)用案例：把日志進(jìn)行集中收集，用于計(jì)算 PV、用戶行為分析等等。

消息通訊

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

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

Push 推消息模型

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

Pull 拉消息模型

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

兩種類型的區(qū)別

兩種類型的區(qū)別如下圖：

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

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

ActiveMQ

ActiveMQ 是由 Apache 出品， ActiveMQ 是一個(gè)完全支持 JMS1.1 和 J2EE1.4 規(guī)范的 JMS Provider 實(shí)現(xiàn)。

它非?？焖伲С侄喾N語言的客戶端和協(xié)議，而且可以非常容易的嵌入到企業(yè)的應(yīng)用環(huán)境中，并有許多高級(jí)功能。

主要特性：

• 服從 JMS 規(guī)范：JMS 規(guī)范提供了良好的標(biāo)準(zhǔn)和保證，包括：同步或異步的消息分發(fā)，一次和僅一次消息分發(fā)，消息接收和訂閱等等。
• 遵從 JMS 規(guī)范的好處在于，不論使用什么 JMS 實(shí)現(xiàn)提供者，這些基礎(chǔ)特性都是可用的。
• 連接靈活性：ActiveMQ 提供了廣泛的連接協(xié)議，支持的協(xié)議有：HTTP/S，IP 多播，SSL，TCP，UDP 等等。對(duì)眾多協(xié)議的支持讓 ActiveMQ 擁有了很好的靈活性。
• 支持的協(xié)議種類多：OpenWire、STOMP、REST、XMPP、AMQP。
• 持久化插件和安全插件：ActiveMQ 提供了多種持久化選擇。而且， ActiveMQ 的安全性也可以完全依據(jù)用戶需求進(jìn)行自定義鑒權(quán)和授權(quán)。
• 支持的客戶端語言種類多：除了 Java 之外，還有 C/C++，.Net，Perl， PHP，Python，Ruby。
• 代理集群：多個(gè) ActiveMQ 代理可以組成一個(gè)集群來提供服務(wù)。
• 異常簡單的管理：ActiveMQ 是以開發(fā)者思維被設(shè)計(jì)的。所以，它并不需要專門的管理員，因?yàn)樗峁┝撕唵斡謱?shí)用的管理特性。

有很多種方法可以監(jiān)控 ActiveMQ 不同層面的數(shù)據(jù)，包括使用在 JConsole 或者在 ActiveMQ 的 WebConsole 中使用 JMX。

通過處理 JMX 的告警消息，通過使用命令行腳本，甚至可以通過監(jiān)控各種類型的日志。

部署環(huán)境：ActiveMQ 可以運(yùn)行在 Java 語言所支持的平臺(tái)之上。

使用 ActiveMQ 需要：

• JavaJDK
• ActiveMQ 安裝包

優(yōu)點(diǎn)如下：

• 跨平臺(tái)(Java 編寫與平臺(tái)無關(guān)，ActiveMQ 幾乎可以運(yùn)行在任何的 JVM上)。
• 可以用 JDBC：可以將數(shù)據(jù)持久化到數(shù)據(jù)庫。雖然使用 JDBC 會(huì)降低 ActiveMQ 的性能，但是數(shù)據(jù)庫一直都是開發(fā)人員最熟悉的存儲(chǔ)介質(zhì)。
• 支持 JMS 規(guī)范：支持 JMS 規(guī)范提供的統(tǒng)一接口。
• 支持自動(dòng)重連和錯(cuò)誤重試機(jī)制。
• 有安全機(jī)制：支持基于 Shiro，JAAS 等多種安全配置機(jī)制，可以對(duì) Queue/Topic 進(jìn)行認(rèn)證和授權(quán)。
• 監(jiān)控完善：擁有完善的監(jiān)控，包括 WebConsole，JMX，Shell 命令行， Jolokia 的 RESTfulAPI。
• 界面友善：提供的 WebConsole 可以滿足大部分情況，還有很多第三方的組件可以使用，比如 Hawtio。

缺點(diǎn)如下：

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

RabbitMQ

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

主要特性如下：

• 可靠性：提供了多種技術(shù)可以讓你在性能和可靠性之間進(jìn)行權(quán)衡。這些技術(shù)包括持久性機(jī)制、投遞確認(rèn)、發(fā)布者證實(shí)和高可用性機(jī)制。
• 靈活的路由：消息在到達(dá)隊(duì)列前是通過交換機(jī)進(jìn)行路由的。RabbitMQ 為典型的路由邏輯提供了多種內(nèi)置交換機(jī)類型。
• 如果你有更復(fù)雜的路由需求，可以將這些交換機(jī)組合起來使用，你甚至可以實(shí)現(xiàn)自己的交換機(jī)類型，并且當(dāng)做 RabbitMQ 的插件來使用。
• 消息集群：在相同局域網(wǎng)中的多個(gè) RabbitMQ 服務(wù)器可以聚合在一起，作為一個(gè)獨(dú)立的邏輯代理來使用。
• 隊(duì)列高可用：隊(duì)列可以在集群中的機(jī)器上進(jìn)行鏡像，以確保在硬件問題下還保證消息安全。
• 支持多種協(xié)議：支持多種消息隊(duì)列協(xié)議。
• 支持多種語言：用 Erlang 語言編寫，支持只要是你能想到的所有編程語言。
• 管理界面：RabbitMQ 有一個(gè)易用的用戶界面，使得用戶可以監(jiān)控和管理消息 Broker 的許多方面。
• 跟蹤機(jī)制：如果消息異常， RabbitMQ 提供消息跟蹤機(jī)制，使用者可以找出發(fā)生了什么。
• 插件機(jī)制：提供了許多插件，來從多方面進(jìn)行擴(kuò)展，也可以編寫自己的插件。
• 部署環(huán)境：RabbitMQ 可以運(yùn)行在 Erlang 語言所支持的平臺(tái)之上，包括 Solaris，BSD，Linux，MacOSX，TRU64，Windows 等。

使用 RabbitMQ 需要：

• ErLang 語言包
• RabbitMQ 安裝包

優(yōu)點(diǎn)如下：

• 由于 Erlang 語言的特性，消息隊(duì)列性能較好，支持高并發(fā)。
• 健壯、穩(wěn)定、易用、跨平臺(tái)、支持多種語言、文檔齊全。
• 有消息確認(rèn)機(jī)制和持久化機(jī)制，可靠性高。
• 高度可定制的路由。
• 管理界面較豐富，在互聯(lián)網(wǎng)公司也有較大規(guī)模的應(yīng)用，社區(qū)活躍度高。

缺點(diǎn)如下：

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

RocketMQ

RocketMQ 出自阿里的開源產(chǎn)品，用 Java 語言實(shí)現(xiàn)，在設(shè)計(jì)時(shí)參考了 Kafka，并做出了自己的一些改進(jìn)，消息可靠性上比 Kafka 更好。

RocketMQ 在阿里內(nèi)部被廣泛應(yīng)用在訂單，交易，充值，流計(jì)算，消息推送，日志流式處理，Binglog 分發(fā)等場景。

主要特性如下：

• 基于隊(duì)列模型：具有高性能、高可靠、高實(shí)時(shí)、分布式等特點(diǎn)。
• Producer、Consumer 隊(duì)列都支持分布式。
• 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ì)列集合。
• 能夠保證嚴(yán)格的消息順序。
• 提供豐富的消息拉取模式。
• 高效的訂閱者水平擴(kuò)展能力。
• 實(shí)時(shí)的消息訂閱機(jī)制。
• 億級(jí)消息堆積能力。
• 較少的外部依賴。

部署環(huán)境：RocketMQ 可以運(yùn)行在 Java 語言所支持的平臺(tái)之上。

使用 RocketMQ 需要：

• JavaJDK
• 安裝 Git、Maven
• RocketMQ 安裝包

優(yōu)點(diǎn)如下：

• 單機(jī)支持 1 萬以上持久化隊(duì)列。
• RocketMQ 的所有消息都是持久化的，先寫入系統(tǒng) PAGECACHE，然后刷盤，可以保證內(nèi)存與磁盤都有一份數(shù)據(jù)，而訪問時(shí)，直接從內(nèi)存讀取。
• 模型簡單，接口易用( JMS 的接口很多場合并不太實(shí)用)。
• 性能非常好，可以允許大量堆積消息在 Broker 中。
• 支持多種消費(fèi)模式，包括集群消費(fèi)、廣播消費(fèi)等。
• 各個(gè)環(huán)節(jié)分布式擴(kuò)展設(shè)計(jì)，支持主從和高可用。
• 開發(fā)度較活躍，版本更新很快。

缺點(diǎn)如下：

• 支持的客戶端語言不多，目前是 Java 及 C++，其中 C++ 還不成熟。
• RocketMQ 社區(qū)關(guān)注度及成熟度也不及前兩者。
• 沒有 Web 管理界面，提供了一個(gè) CLI(命令行界面)管理工具帶來查詢、管理和診斷各種問題。
• 沒有在 MQ 核心里實(shí)現(xiàn) JMS 等接口。

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ò)的特性。

主要特性如下：

• 快速持久化：可以在 O(1) 的系統(tǒng)開銷下進(jìn)行消息持久化。
• 高吞吐：在一臺(tái)普通的服務(wù)器上即可以達(dá)到 10W/S 的吞吐速率。
• 完全的分布式系統(tǒng)：Broker、Producer 和 Consumer 都原生自動(dòng)支持分布式，自動(dòng)實(shí)現(xiàn)負(fù)載均衡。
• 支持同步和異步復(fù)制兩種高可用機(jī)制。
• 支持?jǐn)?shù)據(jù)批量發(fā)送和拉取。
• 零拷貝技術(shù)(zero-copy)：減少 IO 操作步驟，提高系統(tǒng)吞吐量。
• 數(shù)據(jù)遷移、擴(kuò)容對(duì)用戶透明。
• 無需停機(jī)即可擴(kuò)展機(jī)器。
• 其他特性：豐富的消息拉取模型、高效訂閱者水平擴(kuò)展、實(shí)時(shí)的消息訂閱、億級(jí)的消息堆積能力、定期刪除機(jī)制。

部署環(huán)境，使用 Kafka 需要：

• JavaJDK
• Kafka 安裝包

優(yōu)點(diǎn)如下：

• 客戶端語言豐富：支持 Java、.Net、PHP、Ruby、Python、Go 等多種語言。
• 高性能：單機(jī)寫入 TPS 約在 100 萬條/秒，消息大小 10 個(gè)字節(jié)。
• 提供完全分布式架構(gòu)，并有 Replica 機(jī)制，擁有較高的可用性和可靠性，理論上支持消息無限堆積。
• 支持批量操作。
• 消費(fèi)者采用 Pull 方式獲取消息。消息有序，通過控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次。
• 有優(yōu)秀的第三方 Kafka Web 管理界面 Kafka-Manager。
• 在日志領(lǐng)域比較成熟，被多家公司和多個(gè)開源項(xiàng)目使用。

缺點(diǎn)如下：

• Kafka 單機(jī)超過 64 個(gè)隊(duì)列/分區(qū)時(shí)， Load 時(shí)會(huì)發(fā)生明顯的飆高現(xiàn)象。隊(duì)列越多，負(fù)載越高，發(fā)送消息響應(yīng)時(shí)間變長。
• 使用短輪詢方式，實(shí)時(shí)性取決于輪詢間隔時(shí)間。
• 消費(fèi)失敗不支持重試。
• 支持消息順序，但是一臺(tái)代理宕機(jī)后，就會(huì)產(chǎn)生消息亂序。
• 社區(qū)更新較慢。

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

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

Kafka 在于分布式架構(gòu)，RabbitMQ 基于 AMQP 協(xié)議來實(shí)現(xiàn)，RocketMQ 的思路來源于 Kafka，改成了主從結(jié)構(gòu)，在事務(wù)性和可靠性方面做了優(yōu)化。

廣泛來說，電商、金融等對(duì)事務(wù)一致性要求很高的，可以考慮 RabbitMQ 和 RocketMQ，對(duì)性能要求高的可考慮 Kafka。

小結(jié)

本文介紹了消息隊(duì)列的特點(diǎn)，消息隊(duì)列的傳遞服務(wù)模型，消息的傳輸方式，消息的推拉模式。

然后介紹了 ActiveMQ，RabbitMQ，RocketMQ 和 Kafka 幾種常見的消息隊(duì)列，闡述了各種消息隊(duì)列的主要特點(diǎn)和優(yōu)缺點(diǎn)。

通過本文，對(duì)于消息隊(duì)列及相關(guān)技術(shù)選型，相信你會(huì)有更深入的理解和認(rèn)識(shí)。更多細(xì)節(jié)和原理性的東西，還需在實(shí)踐中見真知!

作者：陳林

簡介：五年研發(fā)與架構(gòu)經(jīng)驗(yàn)，曾任職 SAP 中國研發(fā)中心后端研發(fā)、上海冰鑒科技信息科技有限公司架構(gòu)師助理，目前擔(dān)任成都 ThoughtWorks 有限公司高級(jí)咨詢師與研發(fā)人員。熟悉大數(shù)據(jù)、高并發(fā)、負(fù)載均衡、緩存、數(shù)據(jù)庫、消息中間件、搜索引擎、容器和自動(dòng)化等領(lǐng)域。個(gè)人學(xué)習(xí)能力強(qiáng)，技術(shù)熱情高，熱愛開源和寫技術(shù)博客，善于溝通和分享。