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

作者：聞數(shù)起舞 2019-12-13 10:32:56

Kafka在JVM上運(yùn)行(具體來說是Scala)。攝取大量數(shù)據(jù)，通過發(fā)布-訂閱(或排隊(duì))路由。 Broker對消費(fèi)者幾乎一無所知。真正存儲的只是一個(gè)“偏移”值，該值指定使用者在日志中保留的位置。

[[285486]]

現(xiàn)代開源消息中間件對比：

NATS，
RabbitMQ，
Apache Kafka，
Synapse，
NSQ
Pulsar

#NATS：

https://nats.io/

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

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

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

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

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

NATS的用戶包括Buzzfeed，Tinder，Stripe，Rakutan，Ericsson，HTC，Siemens，VMware，Pivotal，GE和Baidu。一個(gè)用例：“我們使用NATS進(jìn)行同步通信，每秒通過它發(fā)送約1萬條消息。。必須說，即使負(fù)載更大(超過10MB)，穩(wěn)定性也很高。我們已經(jīng)在生產(chǎn)環(huán)境中運(yùn)行了幾周，并且沒有任何問題。主要限制是沒有大規(guī)模集群。您可以擁有一個(gè)非常強(qiáng)大的集群，但是每個(gè)節(jié)點(diǎn)只能轉(zhuǎn)發(fā)一次，這是有限制的。”

#RabbitMQ：

RabbitMQ是遵循AMQP 0.9.1標(biāo)準(zhǔn)的代理消息傳遞引擎。它遵循標(biāo)準(zhǔn)的存儲轉(zhuǎn)發(fā)模式，您可以選擇將數(shù)據(jù)存儲在RAM中，在磁盤上，或是在這兩者中。它支持各種消息路由范例。 RabbitMQ可以以集群方式進(jìn)行部署以提高性能，而可以通過鏡像方式進(jìn)行部署，以實(shí)現(xiàn)高可用性。消費(fèi)者直接在隊(duì)列上偵聽，但是發(fā)布者只知道“交換”。這些交換通過綁定(指定路由范式)與綁定鏈接到隊(duì)列。綁定隊(duì)列和事務(wù)傳遞語義。因此，RabbitMQ是一種更為“重量級”的排隊(duì)解決方案，并為此付出額外的費(fèi)用。

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

#Kafka：

基于Scala

使用Kafka，您可以進(jìn)行實(shí)時(shí)處理和批處理。 Kafka在JVM上運(yùn)行(具體來說是Scala)。攝取大量數(shù)據(jù)，通過發(fā)布-訂閱(或排隊(duì))路由。 Broker對消費(fèi)者幾乎一無所知。真正存儲的只是一個(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，美國銀行，房利美，大通銀行等)都使用Kafka。與Nats相比，Kafka更成熟，并且在巨大的數(shù)據(jù)流中表現(xiàn)出色。NATSServer相比Kafka具有部分功能，因?yàn)樗鼘Ｗ⒂讵M窄的用例集。 NATS被設(shè)計(jì)用于以下場景：高性能和低延遲至關(guān)重要，但是如果需要，可以丟失一些數(shù)據(jù)，以跟上數(shù)據(jù)的步伐-NATS文檔將其描述為“一勞永逸”。從結(jié)構(gòu)上講，這是因?yàn)镹ATS沒有持久性層可用于持久存儲數(shù)據(jù)，而Kafka卻具有持久性層(使用群集中的存儲)。為了完全確保消息不會丟失，它看起來像您需要將隊(duì)列聲明為持久+將您的消息標(biāo)記為持久+使用發(fā)布者確認(rèn)。這花費(fèi)了數(shù)百毫秒的延遲。

對于分區(qū)而言，相對安全的唯一隊(duì)列或發(fā)布/訂閱系統(tǒng)是Kafka。當(dāng)您需要5至50臺服務(wù)器時(shí)，Kafka就是一個(gè)非常可靠的工程。擁有那么多服務(wù)器，您每秒可以處理數(shù)百萬條消息，這通常對于中型公司而言已經(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)C2的任何工作，因?yàn)樗荒芴幚碜约旱姆謪^(qū)。換句話說：一個(gè)緩慢的使用者可以阻塞隊(duì)列的很大一部分。 Kafka專為快速(或至少表現(xiàn)均勻)的消費(fèi)者而設(shè)計(jì)。

NATS與Kafka的關(guān)系

NATS最近加入了CNCF(托管Kubernetes，Prometheus等項(xiàng)目-在這里查看Golang的優(yōu)勢!)協(xié)議-Kafka是基于TCP的二進(jìn)制文件，而不是NATS是簡單文本(也基于TCP)的消息傳遞模式-兩者都支持發(fā)布/訂閱和隊(duì)列，但是NATS也支持請求-應(yīng)答(同步和異步)。NATS具有隊(duì)列的概念(當(dāng)然具有唯一的名稱)，并且掛接到同一隊(duì)列的所有訂戶最終都成為一部分屬于同一隊(duì)列組。 (可能多個(gè))訂閱者中只有一個(gè)收到消息。多個(gè)此類隊(duì)列組也將接收同一組消息。這使其成為混合的發(fā)布-訂閱(一對多)和隊(duì)列(點(diǎn)對點(diǎn))。 Kafka通過消費(fèi)者組支持相同的事物，這些用戶組可以從一個(gè)或多個(gè)主題中提取數(shù)據(jù)。流處理— NATS不像Kafka那樣對Kafka Streams提供一流的功能，因此不支持流處理。相對于NATS，NATS提取消息的方式與服務(wù)器本身將消息路由到客戶端的NATS(內(nèi)部維護(hù)興趣圖)相對。NATS可以采取敏感措施，因?yàn)樗梢郧袛嗖环仙a(chǎn)速度的消費(fèi)者，以及不響應(yīng)心跳請求的客戶。消費(fèi)者活躍度檢查也由Kafka執(zhí)行。這是從客戶端本身完成/啟動(dòng)的，因此可能會導(dǎo)致復(fù)雜的情況(例如，當(dāng)您處于消息處理循環(huán)中且未輪詢時(shí))。有很多配置參數(shù)(在客戶端上)可調(diào)整此行為。

交付語義-NATS支持最多一次(At most once)(并且NATS流至少支持一次)，而Kafka則支持僅一次(Exactly once)( NATs似乎沒有像Kafka那樣對分區(qū)/分片消息的概念，在NATS情況下沒有外部依賴性。 Kafka要求Zookeeper，NATS Streaming似乎與Kafka功能集相似，但是使用Go構(gòu)建并且看起來更易于設(shè)置. NATS目前不支持復(fù)制(或?qū)嶋H上沒有任何高可用性設(shè)置)。與Kafka相比，這是一個(gè)主要的缺失功能。

#NSQ：

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

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

NSQ是一種更為傳統(tǒng)的緩沖消息系統(tǒng)。它具有文件持久性，但僅作為 a)優(yōu)化以防止一旦內(nèi)存用完就會丟失消息，以及b)作為使用者檔案。但是，節(jié)點(diǎn)的嚴(yán)重丟失意味著尚未傳遞的那些消息可能會丟失，因?yàn)闊o法保證它們會在其他地方發(fā)布。此外，不能保證發(fā)布到主題和頻道的消息順序是消費(fèi)者接收到的消息順序。使用NSQ，有一個(gè)內(nèi)置實(shí)用程序nsq_to_file，它成為您將每個(gè)消息主題歸檔到磁盤時(shí)的另一個(gè)使用方。它提供了簡單的郵件存檔功能，但不提供任何本地重播功能。

#Apache Pulsar(pulsar.incubator.apache.org)：

基于Java

它是雅虎公司設(shè)計(jì)的，是一種高性能，低延遲，可擴(kuò)展的持久解決方案，用于發(fā)布訂閱消息和消息排隊(duì)。 Apache Pulsar將高性能流(Apache Kafka追求)和靈活的傳統(tǒng)排隊(duì)(RabbitMQ追求)結(jié)合在一起，成為統(tǒng)一的消息傳遞模型和API。 Pulsar使用統(tǒng)一的API為您提供具有相同高性能的流和排隊(duì)系統(tǒng)。總而言之，Kafka的目標(biāo)是高吞吐量，Pulsar的目標(biāo)是低延遲。

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

豐富—持久性/非持久性主題，多租戶，ACL，多DC復(fù)制等。
更易于使用的更靈活的客戶端API(包括CompletableFutures，流暢的接口等)。
Java客戶端組件是線程安全的，消費(fèi)者可以確認(rèn)來自不同的線程的消息

Pulsar 缺點(diǎn)

Java客戶端幾乎沒有Javadoc
Small社區(qū)-當(dāng)前有8個(gè)stackoverflow問題
與BookKeeper綁定的MessageId
與連續(xù)數(shù)字序列的Kafka偏移量相比，消費(fèi)者無法輕松地將自己定位在主題上。讀者無法輕松閱讀關(guān)于該主題的最后一條消息。
沒有事務(wù)支持。
更高的操作復(fù)雜性— Zookeeper + Broker節(jié)點(diǎn)+ BookKeeper —所有clusterLatency都可疑— Broker節(jié)點(diǎn)與BookKeeper之間有一個(gè)額外的遠(yuǎn)程調(diào)用(與Kafka相比)

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