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

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

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

一、＃NATS：

https：//nats.io/

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

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

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

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

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

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

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

二、＃RabbitMQ：

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

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

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

三、＃Kafka：

基于Scala。

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

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

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

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

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

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

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

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

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

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

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

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

2、交付語義

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

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

四、＃NSQ：

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

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

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

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

五、＃ApachePulsar（）：

基于Java。

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

1、Pulsar優(yōu)點：

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

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

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

2、Pulsar缺點：

①Java客戶端幾乎沒有Javadoc

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

③與BookKeeper綁定的MessageId

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

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

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

3、Kafka優(yōu)點：

①特別豐富和有用的JavaDoc。

②KafkaStre