一文幫你選擇開源消息中間件

一文幫你選擇開源消息中間件

現(xiàn)代開源消息中間件對(duì)比，接下來，我們就來一起看看吧！

一、＃NATS：

https：//nats.io/

https：//github./nats-io/nats-streaming-serverNATS最初是使用Ruby構(gòu)建的，每秒可實(shí)現(xiàn)150k消息的消費(fèi)速度。該團(tuán)隊(duì)用Go中重寫了它，現(xiàn)在您可以每秒奇妙地發(fā)送8-11百萬(wàn)條消息。它可以用作發(fā)布-訂閱引擎，但是您也可以把它用于綜合排隊(duì)。

優(yōu)點(diǎn)：口號(hào)：始終可用，撥號(hào)音簡(jiǎn)潔，設(shè)計(jì)低CPU消耗，快速：高速通信總線，高可用性，高可擴(kuò)展性，輕松：體積很小，只有3MBDocker映像！

缺點(diǎn)：忘卻，沒有長(zhǎng)久性：NATS不進(jìn)行長(zhǎng)久性消息傳遞；假如您處于離線狀態(tài)，則不會(huì)收到消息。沒有事務(wù)，沒有增加的交付方式，沒有企業(yè)排隊(duì)。

總的來說，NATS和Redis更適合較小的消息（遠(yuǎn)低于1MB），其中延遲通常在不到毫秒的時(shí)間內(nèi)達(dá)到四個(gè)9.NATS不是HTTP，它是擁有它自己的特別簡(jiǎn)潔的基于文本的協(xié)議，類似于RPC。因此，它不會(huì)在郵件信封中添加任何標(biāo)題。

NATS沒有復(fù)制，分片或整體訂購(gòu)。使用NATS，隊(duì)列可以有效地按節(jié)點(diǎn)分片。假如節(jié)點(diǎn)死亡，則其消息將丟失。到活動(dòng)節(jié)點(diǎn)的傳入消息仍將傳遞給已連接的訂戶，并且訂戶應(yīng)重新連接到可用節(jié)點(diǎn)池。一旦從前死掉的節(jié)點(diǎn)重新加入，它將開頭接收消息。在這種狀況下，NATS會(huì)替換HAProxy之類的內(nèi)容；一個(gè)簡(jiǎn)潔的內(nèi)存路由器，用于懇求后端。

NATS的用戶包括Buzzfeed，Tinder，Stripe，Rakutan，Ericsson，HTC，Siemens，VMware，Pivotal，GE和Baidu。一個(gè)用例：“我們使用NATS進(jìn)行同步通信，每秒通過它發(fā)送約1萬(wàn)條消息。

必需說，即使負(fù)載更大（超過10MB），穩(wěn)定性也很高。我們已經(jīng)在生產(chǎn)環(huán)境中運(yùn)行了幾周，并且沒有任何問題。主要限制是沒有大規(guī)模集群。您可以擁有一個(gè)特別強(qiáng)大的集群，但是每個(gè)節(jié)點(diǎn)只能轉(zhuǎn)發(fā)一次，這是有限制的?！?/p>

二、＃RabbitMQ：

RabbitMQ是遵循AMQP0.9.1標(biāo)準(zhǔn)的代理消息傳遞引擎。它遵循標(biāo)準(zhǔn)的存儲(chǔ)轉(zhuǎn)發(fā)模式，您可以選擇將數(shù)據(jù)存儲(chǔ)在RAM中，在磁盤上，或是在這兩者中。它支持各種消息路由范例。RabbitMQ可以以集群方式進(jìn)行部署以提高性能，而可以通過鏡像方式進(jìn)行部署，以實(shí)現(xiàn)高可用性。

消費(fèi)者直接在隊(duì)列上偵聽，但是發(fā)布者只知道“交換”。這些交換通過綁定（指定路由范式）與綁定鏈接到隊(duì)列。綁定隊(duì)列和事務(wù)傳遞語(yǔ)義。因此，RabbitMQ是一種更為“重量級(jí)”的排隊(duì)解決方案，并為此付出額外的費(fèi)用。

缺點(diǎn)：RabbitMQ的高可用性支持特別糟糕。無論您如何轉(zhuǎn)動(dòng)，它都是單點(diǎn)故障，由于它無法合并由于分區(qū)狀況而導(dǎo)致的沖突隊(duì)列。分區(qū)不僅會(huì)在網(wǎng)絡(luò)中斷時(shí)發(fā)生，還會(huì)在高負(fù)載狀況下發(fā)生。RabbitMQ不會(huì)將消息長(zhǎng)久保存到磁盤。

三、＃Kafka：

基于Scala。

使用Kafka，您可以進(jìn)行實(shí)時(shí)處理和批處理。Kafka在JVM上運(yùn)行（詳細(xì)來說是Scala）。攝取大量數(shù)據(jù)，通過發(fā)布-訂閱（或排隊(duì)）路由。Broker對(duì)消費(fèi)者幾乎一無所知。真正存儲(chǔ)的只是一個(gè)“偏移”值，該值指定使用者在日志中保留的位置。

與很多假定消費(fèi)者主要在線的集成代理不同，Kafka可以勝利保存大量數(shù)據(jù)并支持“重播”方案。該體系結(jié)構(gòu)特別獨(dú)特。主題按分區(qū)排列（用于并行性），分區(qū)跨節(jié)點(diǎn)復(fù)制（以實(shí)現(xiàn)高可用性）。

與Kafka相比，NATS是一個(gè)很小的基礎(chǔ)架構(gòu)，獨(dú)角獸初創(chuàng)公司，物聯(lián)網(wǎng)，健康和大型金融組織（LinkedIn，F(xiàn)B，Netflix，GE，美國(guó)銀行，房利美，大通銀行等）都使用Kafka。與Nats相比，Kafka更成熟，并且在巨大的數(shù)據(jù)流中表現(xiàn)精彩。NATSServer相比Kafka具有部分功能，由于它專注于狹窄的用例集。

NATS被設(shè)計(jì)用于以下場(chǎng)景：高性能和低延遲至關(guān)重要，但是假如需要，可以丟失一些數(shù)據(jù)，以跟上數(shù)據(jù)的步伐-NATS文檔將其描述為“一勞永逸”。從結(jié)構(gòu)上講，這是由于NATS沒有長(zhǎng)久性層可用于長(zhǎng)久存儲(chǔ)數(shù)據(jù)，而Kafka卻具有長(zhǎng)久性層（使用群集中的存儲(chǔ)）。為了完全確保消息不會(huì)丟失，它看起來像您需要將隊(duì)列聲明為長(zhǎng)久+將您的消息標(biāo)記為長(zhǎng)久+使用發(fā)布者確認(rèn)。這花費(fèi)了數(shù)百毫秒的延遲。

對(duì)于分區(qū)而言，相對(duì)平安的唯一隊(duì)列或發(fā)布/訂閱系統(tǒng)是Kafka。當(dāng)您需要5至50臺(tái)服務(wù)器時(shí)，Kafka就是一個(gè)特別牢靠的工程。擁有那么多服務(wù)器，您每秒可以處理數(shù)百萬(wàn)條消息，這通常對(duì)于中型公司而言已經(jīng)足夠。

由于多種緣由，Kafka完全不適合RPC。首先，它的數(shù)據(jù)模型將隊(duì)列中的數(shù)據(jù)分片，每個(gè)分區(qū)只能由一個(gè)使用者使用。假設(shè)我們有分區(qū)1和2。P1為空，P2有大量消息。

現(xiàn)在，當(dāng)C2工作時(shí)，您將擁有一個(gè)空閑的使用者C1。C1無法擔(dān)當(dāng)C2的任何工作，由于它只能處理自己的分區(qū)。換句話說：一個(gè)緩慢的使用者可以堵塞隊(duì)列的很大一部分。Kafka專為快速（或至少表現(xiàn)勻稱）的消費(fèi)者而設(shè)計(jì)。

1、NATS與Kafka的關(guān)系

NATS最近加入了CNCF（托管Kubernetes，Prometheus等項(xiàng)目-在這里查看Golang的優(yōu)勢(shì)?。﹨f(xié)議-Kafka是基于TCP的二進(jìn)制文件，而不是NATS是簡(jiǎn)潔文本（也基于TCP）的消息傳遞模式-兩者都支持發(fā)布/訂閱和隊(duì)列，但是NATS也支持懇求-應(yīng)答（同步和異步）。

NATS具有隊(duì)列的概念（當(dāng)然具有唯一的名稱），并且掛接到同一隊(duì)列的全部訂戶最終都成為一部分屬于同一隊(duì)列組。（可能多個(gè)）訂閱者中只有一個(gè)收到消息。多個(gè)此類隊(duì)列組也將接收同一組消息。這使其成為混合的發(fā)布－訂閱（一對(duì)多）和隊(duì)列（點(diǎn)對(duì)點(diǎn)）。

Kafka通過消費(fèi)者組支持相同的事物，這些用戶組可以從一個(gè)或多個(gè)主題中提取數(shù)據(jù)。流處理—NATS不像Kafka那樣對(duì)KafkaStreams供應(yīng)一流的功能，因此不支持流處理。相對(duì)于NATS，NATS提取消息的方式與服務(wù)器本身將消息路由到客戶端的NATS（內(nèi)部維護(hù)愛好圖）相對(duì)。

NATS可以實(shí)行敏感措施，由于它可以切斷不符合生產(chǎn)速度的消費(fèi)者，以及不響應(yīng)心跳懇求的客戶。消費(fèi)者活躍度檢查也由Kafka執(zhí)行。這是從客戶端本身完成/啟動(dòng)的，因此可能會(huì)導(dǎo)致簡(jiǎn)單的狀況（例如，當(dāng)您處于消息處理循環(huán)中且未輪詢時(shí)）。有許多配置參數(shù)（在客戶端上）可調(diào)整此行為。

2、交付語(yǔ)義

NATS支持最多一次（Atmostonce）（并且NATS流至少支持一次），而Kafka則支持僅一次（Exactlyonce）（NATs好像沒有像Kafka那樣對(duì)分區(qū)/分片消息的概念，在NATS狀況下沒有外部依靠性。

Kafka要求Zookeeper，NATSStreaming好像與Kafka功能集相像，但是使用Go構(gòu)建并且看起來更易于設(shè)置.NATS目前不支持復(fù)制（或?qū)嶋H上沒有任何高可用性設(shè)置）。與Kafka相比，這是一個(gè)主要的缺失功能。

四、＃NSQ：

易于設(shè)置NSQ好像更敏捷，它支持消息長(zhǎng)久性，并且在長(zhǎng)久性要求不高的狀況下，還供應(yīng)類似于NATS的臨時(shí)通道。它配備了NATS缺少的閃亮的管理儀表板。當(dāng)優(yōu)先考慮原始性能時(shí)，NATS很有用.NATS和NSQ隊(duì)列均支持按消息TTL，以修剪時(shí)間敏感消息。

Kafka很簡(jiǎn)單，但保證不會(huì)丟失任何數(shù)據(jù)。適合訂購(gòu)日志。NSQ缺乏長(zhǎng)久性和復(fù)制力量。大規(guī)模操作特別簡(jiǎn)潔。Kafka的性能和增加的保證以難以操作為代價(jià)。有了Kafka，除了Kafka經(jīng)紀(jì)人，您還需要一個(gè)Zookeeper集群。Kafka需要考慮分區(qū)和偏移量，最好將Kafka視為分布式日志服務(wù)，而不是消息傳遞代理，例如數(shù)據(jù)庫(kù)中的預(yù)寫日志而不是printf語(yǔ)句。

NSQ是一種更為傳統(tǒng)的緩沖消息系統(tǒng)。它具有文件長(zhǎng)久性，但僅作為a）優(yōu)化以防止一旦內(nèi)存用完就會(huì)丟失消息，以及b）作為使用者檔案。但是，節(jié)點(diǎn)的嚴(yán)峻丟失意味著尚未傳遞的那些消息可能會(huì)丟失，由于無法保證它們會(huì)在其他地方發(fā)布。

此外，不能保證發(fā)布到主題和頻道的消息挨次是消費(fèi)者接收到的消息挨次。使用NSQ，有一個(gè)內(nèi)置有用程序nsq_to_file，它成為您將每個(gè)消息主題歸檔到磁盤時(shí)的另一個(gè)使用方。它供應(yīng)了簡(jiǎn)潔的郵件存檔功能，但不供應(yīng)任何本地重播功能。

五、＃ApachePulsar（）：

基于Java。

它是雅虎公司設(shè)計(jì)的，是一種高性能，低延遲，可擴(kuò)展的長(zhǎng)久解決方案，用于發(fā)布訂閱消息和消息排隊(duì)。ApachePulsar將高性能流（ApacheKafka追求）和敏捷的傳統(tǒng)排隊(duì)（RabbitMQ追求）結(jié)合在一起，成為統(tǒng)一的消息傳遞模型和API。Pulsar使用統(tǒng)一的API為您供應(yīng)具有相同高性能的流和排隊(duì)系統(tǒng)?？偠灾?，Kafka的目標(biāo)是高吞吐量，Pulsar的目標(biāo)是低延遲。

1、Pulsar優(yōu)點(diǎn)：

①豐富—長(zhǎng)久性/非長(zhǎng)久性主題，多租戶，ACL，多DC復(fù)制等。

②更易于使用的更敏捷的客戶端API（包括CompletableFutures，流暢的接口等）。

③Java客戶端組件是線程平安的，消費(fèi)者可以確認(rèn)來自不同的線程的消息

2、Pulsar缺點(diǎn)：

①Java客戶端幾乎沒有Javadoc

②Small社區(qū)-當(dāng)前有8個(gè)stackoverflow問題

③與BookKeeper綁定的MessageId

④與連續(xù)數(shù)字序列的Kafka偏移量相比，消費(fèi)者無法輕松地將自己定位在主題上。讀者無法輕松閱讀關(guān)于該主題的最終一條消息。

⑤沒有事務(wù)支持。

⑥更高的操作簡(jiǎn)單性—Zookeeper+Broker節(jié)點(diǎn)+BookKeeper—全部clusterLatency都可疑—Broker節(jié)點(diǎn)與BookKeeper之間有一個(gè)額外的遠(yuǎn)程調(diào)用（與Kafka相比）

3、Kafka優(yōu)點(diǎn)：

①特別豐富和有用的JavaDoc。

②KafkaStre