RabbitMQ

RabbitMQ是實(shí)現(xiàn)AMQP協(xié)議(0.9.1) 的消息中間件的一種，由RabbitMQ Technologies Ltd開(kāi)發(fā)并且提供商業(yè)支持的，最初起源于金融系統(tǒng)，服務(wù)器端用Erlang語(yǔ)言編寫，用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息，在易用性、擴(kuò)展性、高可用性等方面表現(xiàn)不俗。

RabbitMQ基本概念

• Broker： 簡(jiǎn)單來(lái)說(shuō)就是消息隊(duì)列服務(wù)器實(shí)體
• Exchange： 消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個(gè)隊(duì)列
• Queue： 消息隊(duì)列載體，每個(gè)消息都會(huì)被投入到一個(gè)或多個(gè)隊(duì)列
• Binding： 綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來(lái)
• Routing Key： 路由關(guān)鍵字，exchange根據(jù)這個(gè)關(guān)鍵字進(jìn)行消息投遞
• VHost： vhost 可以理解為虛擬 broker ，即 mini-RabbitMQ server。其內(nèi)部均含有獨(dú)立的 queue、exchange 和 binding 等，但最最重要的是，其擁有獨(dú)立的權(quán)限系統(tǒng)，可以做到 vhost 范圍的用戶控制。當(dāng)然，從 RabbitMQ 的全局角度，vhost 可以作為不同權(quán)限隔離的手段（一個(gè)典型的例子就是不同的應(yīng)用可以跑在不同的 vhost 中）。
• Producer： 消息生產(chǎn)者，就是投遞消息的程序
• Consumer： 消息消費(fèi)者，就是接受消息的程序
• Channel： 消息通道，在客戶端的每個(gè)連接里，可建立多個(gè)channel，每個(gè)channel代表一個(gè)會(huì)話任務(wù)

由Exchange、Queue、RoutingKey三個(gè)才能決定一個(gè)從Exchange到Queue的唯一的線路。

RabbitMQ處理流程

1.Producer會(huì)先建立Channel，建立到Broker上Virtual Host的連接，接下來(lái)就可以向這個(gè)Virtual Host中的Exchange發(fā)送消息。

2.Producer把消息發(fā)布到Exchange上，消息最終到達(dá)隊(duì)列并被消費(fèi)者接收，而B(niǎo)inding決定交換器的消息應(yīng)該發(fā)送到那個(gè)隊(duì)列。Exchange能夠處理消息的前提是，它至少已經(jīng)和某個(gè)Queue或者另外的Exchange形成了綁定關(guān)系，并設(shè)置好了到這些Queue和Excahnge的路由規(guī)則。在Exchange收到消息后，會(huì)根據(jù)設(shè)置的路由規(guī)則，將消息發(fā)送到符合要求的Queue或者Exchange中（路由規(guī)則與Message中的Routing Key屬性配合使用）。

3.當(dāng)Queue收到消息后，會(huì)進(jìn)行如下處理：

• 如果當(dāng)前沒(méi)有Consumer的Channel連接到這個(gè)Queue，那么Queue將會(huì)把這條消息進(jìn)行存儲(chǔ)，直到有Channel被創(chuàng)建。
• 如果已經(jīng)有Channel連接到這個(gè)Queue，那么消息將會(huì)按順序發(fā)送給這個(gè)Channel。

4.當(dāng)Consumer收到消息后，就可以進(jìn)行消息的處理：

• Consumer在完成某一條消息的處理后，將需要手動(dòng)的發(fā)送一條ACK消息到對(duì)應(yīng)的Queue，也可以設(shè)置為自動(dòng)發(fā)送或者無(wú)需發(fā)送。
• Queue在接收到這條ACK信息后，才認(rèn)為這條消息處理成功，并將這條消息從Queue中移除。
• 如果在對(duì)應(yīng)的Channel斷開(kāi)后，Queue都沒(méi)有這條消息的ACK信息，這條消息將會(huì)重新被發(fā)送給另外的Channel。也可以直接發(fā)送NACK信息，這樣這條消息將會(huì)立即歸隊(duì)，并發(fā)送給另外的Channel。

RabbitMQ的工作模式

simple模式（即最簡(jiǎn)單的收發(fā)模式）

1.消息產(chǎn)生消息，將消息放入隊(duì)列

2.消息的消費(fèi)者(consumer) 監(jiān)聽(tīng) 消息隊(duì)列,如果隊(duì)列中有消息,就消費(fèi)掉,消息被拿走后,自動(dòng)從隊(duì)列中刪除(隱患 消息可能沒(méi)有被消費(fèi)者正確處理,已經(jīng)從隊(duì)列中消失了,造成消息的丟失，這里可以設(shè)置成手動(dòng)的ack,但如果設(shè)置成手動(dòng)ack，處理完后要及時(shí)發(fā)送ack消息給隊(duì)列，否則會(huì)造成內(nèi)存溢出)。

work工作模式(資源的競(jìng)爭(zhēng))

1.消息產(chǎn)生者將消息放入隊(duì)列。

2.消費(fèi)者可以有多個(gè),消費(fèi)者1,消費(fèi)者2同時(shí)監(jiān)聽(tīng)同一個(gè)隊(duì)列,消息被消費(fèi)。C1 C2共同爭(zhēng)搶當(dāng)前的消息隊(duì)列內(nèi)容,誰(shuí)先拿到誰(shuí)負(fù)責(zé)消費(fèi)消息(隱患：高并發(fā)情況下,默認(rèn)會(huì)產(chǎn)生某一個(gè)消息被多個(gè)消費(fèi)者共同使用,可以設(shè)置一個(gè)開(kāi)關(guān)(syncronize) 保證一條消息只能被一個(gè)消費(fèi)者使用)。

publish/subscribe發(fā)布訂閱(共享資源)

1、每個(gè)消費(fèi)者監(jiān)聽(tīng)自己的隊(duì)列；

2、生產(chǎn)者將消息發(fā)給broker，由交換機(jī)將消息轉(zhuǎn)發(fā)到綁定此交換機(jī)的每個(gè)隊(duì)列，每個(gè)綁定交換機(jī)的隊(duì)列都將接收到消息。

routing路由模式

1.消息生產(chǎn)者將消息發(fā)送給交換機(jī)按照路由判斷,路由是字符串(info) 當(dāng)前產(chǎn)生的消息攜帶路由字符(對(duì)象的方法),交換機(jī)根據(jù)路由的key,只能匹配上路由key對(duì)應(yīng)的消息隊(duì)列,對(duì)應(yīng)的消費(fèi)者才能消費(fèi)消息;

2.根據(jù)業(yè)務(wù)功能定義路由字符串

3.從系統(tǒng)的代碼邏輯中獲取對(duì)應(yīng)的功能字符串,將消息任務(wù)扔到對(duì)應(yīng)的隊(duì)列中。

4.業(yè)務(wù)場(chǎng)景:error 通知;EXCEPTION;錯(cuò)誤通知的功能;傳統(tǒng)意義的錯(cuò)誤通知;客戶通知;利用key路由,可以將程序中的錯(cuò)誤封裝成消息傳入到消息隊(duì)列中,開(kāi)發(fā)者可以自定義消費(fèi)者,實(shí)時(shí)接收錯(cuò)誤;

topic 主題模式(路由模式的一種)

1.星號(hào)(*)井號(hào)(#)代表通配符

2.星號(hào)(*)代表多個(gè)單詞,井號(hào)(#)代表一個(gè)單詞

3.路由功能添加模糊匹配

4.消息產(chǎn)生者產(chǎn)生消息,把消息交給交換機(jī)

5.交換機(jī)根據(jù)key的規(guī)則模糊匹配到對(duì)應(yīng)的隊(duì)列,由隊(duì)列的監(jiān)聽(tīng)消費(fèi)者接收消息消費(fèi)

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

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

RabbitMQ缺點(diǎn)

• 盡管結(jié)合erlang語(yǔ)言本身的并發(fā)優(yōu)勢(shì)，性能較好，但是不利于做二次開(kāi)發(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ù)成本較高；

Kafka

Kafka是由Apache軟件基金會(huì)開(kāi)發(fā)的一個(gè)開(kāi)源流處理平臺(tái)，由Scala和Java編寫。Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費(fèi)者規(guī)模的網(wǎng)站中的所有動(dòng)作流數(shù)據(jù)。 這種動(dòng)作（網(wǎng)頁(yè)瀏覽，搜索和其他用戶的行動(dòng)）是在現(xiàn)代網(wǎng)絡(luò)上的許多社會(huì)功能的一個(gè)關(guān)鍵因素。 這些數(shù)據(jù)通常是由于吞吐量的要求而通過(guò)處理日志和日志聚合來(lái)解決。 對(duì)于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。Kafka的目的是通過(guò)Hadoop的并行加載機(jī)制來(lái)統(tǒng)一線上和離線的消息處理，也是為了通過(guò)集群來(lái)提供實(shí)時(shí)的消息。

Kafka基本概念

• Broker

  消息中間件處理節(jié)點(diǎn)，一個(gè)Kafka節(jié)點(diǎn)就是一個(gè)Broker，一個(gè)或者多個(gè)Broker可以組成一個(gè)Kafka集群

• Topic

  每條發(fā)布到Kafka集群的消息都有一個(gè)類別，這個(gè)類別被稱為Topic。（物理上不同Topic的消息分開(kāi)存儲(chǔ)，邏輯上一個(gè)Topic的消息雖然保存于一個(gè)或多個(gè)broker上但用戶只需指定消息的Topic即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處）

• Partition

  用于存放消息的隊(duì)列，存放的消息都是有序的，同一主題可以分多個(gè)Partition，如分多個(gè)Partiton時(shí)，同樣會(huì)以如partition1存放1、3、5消息，partition2存放2、4、6消息

• Producer

  消息生產(chǎn)者，向Broker發(fā)送消息的客戶端

• Consumer

  消息消費(fèi)者，從Broker讀取消息的客戶端，Consumer是通過(guò)offset進(jìn)行標(biāo)識(shí)消息被消費(fèi)的位置

• Consumer Group

  每個(gè)Consumer屬于一個(gè)特定的Consumer Group，一條消息可以發(fā)送到多個(gè)不同的Consumer Group，但是同一個(gè)Consumer Group中只能有一個(gè)Consumer能夠消費(fèi)該消息

Kafka數(shù)據(jù)處理步驟

• Producer產(chǎn)生消息，發(fā)送到Broker中
• Leader狀態(tài)的Broker接收消息，寫入到相應(yīng)topic中
• Leader狀態(tài)的Broker接收完畢以后，傳給Follow狀態(tài)的Broker作為副本備份
• Consumer消費(fèi)Broker中的消息

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

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

Kafka缺點(diǎn)

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

RocketMQ

RocketMQ 是阿里巴巴在2012年開(kāi)源的分布式消息中間件，目前已經(jīng)捐贈(zèng)給 Apache 軟件基金會(huì)，并于2017年9月25日成為 Apache 的頂級(jí)項(xiàng)目。作為經(jīng)歷過(guò)多次阿里巴巴雙十一這種“超級(jí)工程”的洗禮并有穩(wěn)定出色表現(xiàn)的國(guó)產(chǎn)中間件，以其高性能、低延時(shí)和高可靠等特性近年來(lái)已經(jīng)也被越來(lái)越多的國(guó)內(nèi)企業(yè)使用。

RocketMQ基本概念

生產(chǎn)者組（Producer）

負(fù)責(zé)產(chǎn)生消息，生產(chǎn)者向消息服務(wù)器發(fā)送由業(yè)務(wù)應(yīng)用程序系統(tǒng)生成的消息。 RocketMQ 提供了三種方式發(fā)送消息：同步、異步和單向。

名稱服務(wù)器（NameServer）

主要負(fù)責(zé)對(duì)于源數(shù)據(jù)的管理，包括了對(duì)于Topic和路由信息的管理。

NameServer 被設(shè)計(jì)成幾乎無(wú)狀態(tài)的，可以橫向擴(kuò)展，節(jié)點(diǎn)之間相互之間無(wú)通信，通過(guò)部署多臺(tái)機(jī)器來(lái)標(biāo)記自己是一個(gè)偽集群。每個(gè) Broker 在啟動(dòng)的時(shí)候會(huì)到 NameServer 注冊(cè)，Producer 在發(fā)送消息前會(huì)根據(jù) Topic 到 NameServer 獲取到 Broker 的路由信息，Consumer 也會(huì)定時(shí)獲取 Topic 的路由信息。所以從功能上看應(yīng)該是和 ZooKeeper 差不多，RocketMQ 的早期版本確實(shí)是使用的 ZooKeeper ，后來(lái)改為了自己實(shí)現(xiàn)的 NameServer 。

消息服務(wù)器（Broker）

是消息存儲(chǔ)中心，主要作用是接收來(lái)自 Producer 的消息并存儲(chǔ)， Consumer 從這里取得消息。它還存儲(chǔ)與消息相關(guān)的元數(shù)據(jù)，包括用戶組、消費(fèi)進(jìn)度偏移量、隊(duì)列信息等。從部署結(jié)構(gòu)圖中可以看出 Broker 有 Master 和 Slave 兩種類型，Master 既可以寫又可以讀，Slave不可以寫只可以讀。從物理結(jié)構(gòu)上看 Broker 的集群部署方式有四種：單 Master 、多 Master 、多 Master 多 Slave（同步刷盤）、多 Master多 Slave（異步刷盤）。

消費(fèi)者組（Consumer）

負(fù)責(zé)消費(fèi)消息，消費(fèi)者從消息服務(wù)器拉取信息并將其輸入用戶應(yīng)用程序,支持PUSH和PULL兩種消費(fèi)模式，支持集群消費(fèi)和廣播消息，提供實(shí)時(shí)的消息訂閱機(jī)制。

• Pull：拉取型消費(fèi)者（Pull Consumer）主動(dòng)從消息服務(wù)器拉取信息，只要批量拉取到消息，用戶應(yīng)用就會(huì)啟動(dòng)消費(fèi)過(guò)程，所以 Pull 稱為主動(dòng)消費(fèi)型。
• Push：推送型消費(fèi)者（Push Consumer）封裝了消息的拉取、消費(fèi)進(jìn)度和其他的內(nèi)部維護(hù)工作，將消息到達(dá)時(shí)執(zhí)行的回調(diào)接口留給用戶應(yīng)用程序來(lái)實(shí)現(xiàn)。所以 Push 稱為被動(dòng)消費(fèi)類型，但從實(shí)現(xiàn)上看還是從消息服務(wù)器中拉取消息，不同于 Pull 的是 Push 首先要注冊(cè)消費(fèi)監(jiān)聽(tīng)器，當(dāng)監(jiān)聽(tīng)器處觸發(fā)后才開(kāi)始消費(fèi)消息。

RocketMQ特性

1.靈活可擴(kuò)展性 ： 天然支持集群，其核心四組件（Name Server、Broker、Producer、Consumer）每一個(gè)都可以在沒(méi)有單點(diǎn)故障的情況下進(jìn)行水平擴(kuò)展。

2.海量消息堆積： 采用零拷貝原理實(shí)現(xiàn)超大的消息的堆積能力，據(jù)說(shuō)單機(jī)已可以支持億級(jí)消息堆積，而且在堆積了這么多消息后依然保持寫入低延遲。

3.順序消息： 可以保證消息消費(fèi)者按照消息發(fā)送的順序?qū)ο⑦M(jìn)行消費(fèi)。順序消息分為全局有序和局部有序，一般推薦使用局部有序，即生產(chǎn)者通過(guò)將某一類消息按順序發(fā)送至同一個(gè)隊(duì)列來(lái)實(shí)現(xiàn)。

4.消息過(guò)濾： 分為在服務(wù)器端過(guò)濾和在消費(fèi)端過(guò)濾。服務(wù)器端過(guò)濾時(shí)可以按照消息消費(fèi)者的要求做過(guò)濾，優(yōu)點(diǎn)是減少不必要消息傳輸，缺點(diǎn)是增加了消息服務(wù)器的負(fù)擔(dān)，實(shí)現(xiàn)相對(duì)復(fù)雜。消費(fèi)端過(guò)濾則完全由具體應(yīng)用自定義實(shí)現(xiàn)，這種方式更加靈活，缺點(diǎn)是很多無(wú)用的消息會(huì)傳輸給消息消費(fèi)者。

5.事務(wù)消息： 除了支持普通消息，順序消息之外還支持事務(wù)消息，這個(gè)特性對(duì)于分布式事務(wù)來(lái)說(shuō)提供了又一種解決思路。

6.消息回溯： 是指消費(fèi)者已經(jīng)消費(fèi)成功的消息，由于業(yè)務(wù)上需求需要重新消費(fèi)，RocketMQ 支持按照時(shí)間回溯消費(fèi)，時(shí)間維度精確到毫秒，可以向前回溯，也可以向后回溯。

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

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

RocketMQ缺點(diǎn)

• 支持的客戶端語(yǔ)言不多，目前是java及c++，其中c++不成熟；
• RocketMQ社區(qū)關(guān)注度及成熟度不高；
• 沒(méi)有web管理界面，提供了一個(gè)CLI(命令行界面)管理工具帶來(lái)查詢、管理和診斷各種問(wèn)題；
• 沒(méi)有在 mq 核心中去實(shí)現(xiàn)JMS等接口；

ActiveMQ

ActiveMQ是由Apache出品，旨在為應(yīng)用程序提供高效、可擴(kuò)展、穩(wěn)定、安全的企業(yè)級(jí)消息通信，它是一個(gè)完全支持JMS1.1和J2EE 1.4規(guī)范的JMS Provider實(shí)現(xiàn)，比如 JMX 管理、主從管理、消息組通信、消息優(yōu)先級(jí)、延遲接收消息、虛擬接收者、消息持久化、消息隊(duì)列監(jiān)控等等。它非?？焖?#xff0c;支持多種語(yǔ)言的客戶端和協(xié)議，而且可以非常容易的嵌入到企業(yè)的應(yīng)用環(huán)境中，并有許多高級(jí)功能。
和上面的mq類似，主要的基本組件有Broker、Producer、Consumer、Topic、Queue、Message

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

• 跨平臺(tái)(JAVA編寫與平臺(tái)無(wú)關(guān)有，ActiveMQ幾乎可以運(yùn)行在任何的JVM上)
• 可以用JDBC：可以將數(shù)據(jù)持久化到數(shù)據(jù)庫(kù)。雖然使用JDBC會(huì)降低ActiveMQ的性能，但是數(shù)據(jù)庫(kù)一直都是開(kāi)發(fā)人員最熟悉的存儲(chǔ)介質(zhì)。將消息存到數(shù)據(jù)庫(kù)，看得見(jiàn)摸得著。而且公司有專門的DBA去對(duì)數(shù)據(jù)庫(kù)進(jìn)行調(diào)優(yōu)，主從分離；
• 支持JMS ：支持JMS的統(tǒng)一接口;
• 支持自動(dòng)重連；
• 有安全機(jī)制：支持基于shiro，jaas等多種安全配置機(jī)制，可以對(duì)Queue/Topic進(jìn)行認(rèn)證和授權(quán)。
• 監(jiān)控完善：擁有完善的監(jiān)控，包括Web Console，JMX，Shell命令行，Jolokia的REST API；
• 界面友善：提供的Web Console可以滿足大部分情況，還有很多第三方的組件可以使用，如hawtio；

ActiveMQ缺點(diǎn)

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

RabbitMQ、Kafka、RocketMQ、ActiveMQ對(duì)比

特性	RabbitMQ	Kafka	RocketMQ	ActiveMQ
開(kāi)發(fā)語(yǔ)言	Erlang	Scala&Java	Java	Java
客戶端支持	官方支持Erlang、Java、Ruby等，社區(qū)產(chǎn)出多語(yǔ)言API，幾乎支持所有常用語(yǔ)言	官方支持Java，社區(qū)有多語(yǔ)言版本，如PHP、Python、Go、C/C++、Ruby、NodeJs等	Java、C++	Java、C/C++、Python、PHP、Perl、.net等
協(xié)議支持	AMQP、XMPP、SMTP、SMTOP	自定義協(xié)議，社區(qū)提供了HTTP協(xié)議支持	自定義協(xié)議，社區(qū)提供JMS	OpenWire、SMTOP、REST、XMPP、AMQP
可用性	高，基于主從架構(gòu)實(shí)現(xiàn)高可用	很高，分布式，一個(gè)數(shù)據(jù)多個(gè)副本，少數(shù)機(jī)器宕機(jī)，不會(huì)丟失數(shù)據(jù)，不會(huì)導(dǎo)致不可用	很高，分布式架構(gòu)	高，基于主從架構(gòu)實(shí)現(xiàn)高可用
集群	支持	支持	支持	支持
負(fù)載均衡	支持	支持	支持	支持
單機(jī)吞吐量	萬(wàn)級(jí)	十萬(wàn)級(jí)	十萬(wàn)級(jí)	萬(wàn)級(jí)
topic數(shù)量對(duì)吞吐量的影響	-	topic從幾十到幾百個(gè)時(shí)候，吞吐量會(huì)大幅度下降，因?yàn)镵afka的每個(gè)Topic、每個(gè)分區(qū)都會(huì)對(duì)應(yīng)一個(gè)物理文件，若需要支撐大規(guī)模的topic，則需要增加更多的機(jī)器資源	topic達(dá)到幾百/幾千的級(jí)別后，吞吐量會(huì)有較小幅度的下降，在同等機(jī)器下，可以支撐大量的 topic	-
消息批量操作	不支持	支持	支持	支持
消息推拉模式	pull/push均支持	pull	pull/push均支持	pull/push均支持
消息可靠性	支持最少投遞一次	支持最少投遞一次	支持最少投遞一次	有較低的概率丟失數(shù)據(jù)
消息延遲	微秒級(jí) (最快)	毫秒級(jí)	毫秒級(jí)	毫秒級(jí)
持久化能力	內(nèi)存、文件，支持?jǐn)?shù)據(jù)堆積，但影響生產(chǎn)速率	磁盤文件，只要容量夠，可以做到無(wú)限堆積	磁盤文件	內(nèi)存、文件、數(shù)據(jù)庫(kù)
事務(wù)消息	不支持	不支持	支持	支持
死信	支持	不支持	支持	支持
消息回放	不支持	支持offset維度回放	支持offset維度回放	不支持
延遲隊(duì)列	支持	不支持	支持	支持