導(dǎo)言

作為一個(gè)有豐富經(jīng)驗(yàn)的微服務(wù)系統(tǒng)架構(gòu)師，經(jīng)常有人問(wèn)我，“應(yīng)該選擇RabbitMQ還是Kafka？”。基于某些原因， 許多開(kāi)發(fā)者會(huì)把這兩種技術(shù)當(dāng)做等價(jià)的來(lái)看待。的確，在一些案例場(chǎng)景下選擇RabbitMQ還是Kafka沒(méi)什么差別，但是這兩種技術(shù)在底層實(shí)現(xiàn)方面是有許多差異的。不同的場(chǎng)景需要不同的解決方案，選錯(cuò)一個(gè)方案能夠嚴(yán)重的影響你對(duì)軟件的設(shè)計(jì)，開(kāi)發(fā)和維護(hù)的能力。這篇文章會(huì)先介紹一下基本的異步消息模式，然后再介紹一下RabbitMQ和Kafka以及他們的內(nèi)部結(jié)構(gòu)信息。第二部分(未完成)主要介紹這兩種技術(shù)的主要不同點(diǎn)以及他們各自的優(yōu)缺點(diǎn)，最后我們會(huì)說(shuō)明一下怎樣選擇這兩種技術(shù)。異步消息模式

異步消息可以作為解耦消息的生產(chǎn)和處理的一種解決方案。提到消息系統(tǒng)，我們通常會(huì)想到兩種主要的消息模式——消息隊(duì)列和發(fā)布/訂閱模式。消息隊(duì)列利用消息隊(duì)列可以解耦生產(chǎn)者和消費(fèi)者。多個(gè)生產(chǎn)者可以向同一個(gè)消息隊(duì)列發(fā)送消息；但是，一個(gè)消息在被一個(gè)消息者處理的時(shí)候，這個(gè)消息在隊(duì)列上會(huì)被鎖住或者被移除并且其他消費(fèi)者無(wú)法處理該消息。也就是說(shuō)一個(gè)具體的消息只能由一個(gè)消費(fèi)者消費(fèi)。

消息隊(duì)列需要額外注意的是，如果消費(fèi)者處理一個(gè)消息失敗了，消息系統(tǒng)一般會(huì)把這個(gè)消息放回隊(duì)列，這樣其他消費(fèi)者可以繼續(xù)處理。消息隊(duì)列除了提供解耦功能之外，它還能夠?qū)ιa(chǎn)者和消費(fèi)者進(jìn)行獨(dú)立的伸縮(scale)，以及提供對(duì)錯(cuò)誤處理的容錯(cuò)能力。發(fā)布/訂閱發(fā)布/訂閱(pub/sub)模式中，單個(gè)消息可以被多個(gè)訂閱者并發(fā)的獲取和處理。

發(fā)布/訂閱例如，一個(gè)系統(tǒng)中產(chǎn)生的事件可以通過(guò)這種模式讓發(fā)布者通知所有訂閱者。在許多隊(duì)列系統(tǒng)中常常用主題(topics)這個(gè)術(shù)語(yǔ)指代發(fā)布/訂閱模式。在RabbitMQ中，主題就是發(fā)布/訂閱模式的一種具體實(shí)現(xiàn)(更準(zhǔn)確點(diǎn)說(shuō)是交換器(exchange)的一種)，但是在這篇文章中，我會(huì)把主題和發(fā)布/訂閱當(dāng)做等價(jià)來(lái)看待。一般來(lái)說(shuō)，訂閱有兩種類(lèi)型：

臨時(shí)(ephemeral)訂閱，這種訂閱只有在消費(fèi)者啟動(dòng)并且運(yùn)行的時(shí)候才存在。一旦消費(fèi)者退出，相應(yīng)的訂閱以及尚未處理的消息就會(huì)丟失。

持久(durable)訂閱，這種訂閱會(huì)一直存在，除非主動(dòng)去刪除。消費(fèi)者退出后，消息系統(tǒng)會(huì)繼續(xù)維護(hù)該訂閱，并且后續(xù)消息可以被繼續(xù)處理。

RabbitMQ

RabbitMQ作為消息中間件的一種實(shí)現(xiàn)，常常被當(dāng)作一種服務(wù)總線來(lái)使用。RabbitMQ原生就支持上面提到的兩種消息模式。其他一些流行的消息中間件的實(shí)現(xiàn)有ActiveMQ，ZeroMQ，Azure Service Bus以及Amazon Simple Queue Service(SQS)。這些消息中間件的實(shí)現(xiàn)有許多共通的地方；這邊文章中提到的許多概念大部分都適用于這些中間件。隊(duì)列RabbitMQ支持典型的開(kāi)箱即用的消息隊(duì)列。開(kāi)發(fā)者可以定義一個(gè)命名隊(duì)列，然后發(fā)布者可以向這個(gè)命名隊(duì)列中發(fā)送消息。最后消費(fèi)者可以通過(guò)這個(gè)命名隊(duì)列獲取待處理的消息。消息交換器RabbitMQ使用消息交換器來(lái)實(shí)現(xiàn)發(fā)布/訂閱模式。發(fā)布者可以把消息發(fā)布到消息交換器上而不用知道這些消息都有哪些訂閱者。每一個(gè)訂閱了交換器的消費(fèi)者都會(huì)創(chuàng)建一個(gè)隊(duì)列；然后消息交換器會(huì)把生產(chǎn)的消息放入隊(duì)列以供消費(fèi)者消費(fèi)。消息交換器也可以基于各種路由規(guī)則為一些訂閱者過(guò)濾消息。

RabbitMQ消息交換器需要重點(diǎn)注意的是RabbitMQ支持臨時(shí)和持久兩種訂閱類(lèi)型。消費(fèi)者可以調(diào)用RabbitMQ的API來(lái)選擇他們想要的訂閱類(lèi)型。根據(jù)RabbitMQ的架構(gòu)設(shè)計(jì)，我們也可以創(chuàng)建一種混合方法——訂閱者以組隊(duì)的方式然后在組內(nèi)以競(jìng)爭(zhēng)關(guān)系作為消費(fèi)者去處理某個(gè)具體隊(duì)列上的消息，這種由訂閱者構(gòu)成的組我們稱為消費(fèi)者組。按照這種方式，我們實(shí)現(xiàn)了發(fā)布/訂閱模式，同時(shí)也能夠很好的伸縮(scale-up)訂閱者去處理收到的消息。

發(fā)布/訂閱與隊(duì)列的聯(lián)合使用Apache Kafka

Apache Kafka不是消息中間件的一種實(shí)現(xiàn)。相反，它只是一種分布式流式系統(tǒng)。不同于基于隊(duì)列和交換器的RabbitMQ，Kafka的存儲(chǔ)層是使用分區(qū)事務(wù)日志來(lái)實(shí)現(xiàn)的。Kafka也提供流式API用于實(shí)時(shí)的流處理以及連接器API用來(lái)更容易的和各種數(shù)據(jù)源集成；當(dāng)然，這些已經(jīng)超出了本篇文章的討論范圍。云廠商為Kafka存儲(chǔ)層提供了可選的方案，比如Azure Event Hubsy以及AWS Kinesis Data Streams等。對(duì)于Kafka流式處理能力，還有一些特定的云方案和開(kāi)源方案，不過(guò)，話說(shuō)回來(lái)，它們也超出了本篇的范圍。主題Kafka沒(méi)有實(shí)現(xiàn)隊(duì)列這種東西。相應(yīng)的，Kafka按照類(lèi)別存儲(chǔ)記錄集，并且把這種類(lèi)別稱為主題。Kafka為每個(gè)主題維護(hù)一個(gè)消息分區(qū)日志。每個(gè)分區(qū)都是由有序的不可變的記錄序列組成，并且消息都是連續(xù)的被追加在尾部。當(dāng)消息到達(dá)時(shí)，Kafka就會(huì)把他們追加到分區(qū)尾部。默認(rèn)情況下，Kafka使用輪詢分區(qū)器(partitioner)把消息一致的分配到多個(gè)分區(qū)上。Kafka可以改變創(chuàng)建消息邏輯流的行為。例如，在一個(gè)多租戶的應(yīng)用中，我們可以根據(jù)每個(gè)消息中的租戶ID創(chuàng)建消息流。IoT場(chǎng)景中，我們可以在常數(shù)級(jí)別下根據(jù)生產(chǎn)者的身份信息(identity)將其映射到一個(gè)具體的分區(qū)上。確保來(lái)自相同邏輯流上的消息映射到相同分區(qū)上，這就保證了消息能夠按照順序提供給消費(fèi)者。

Kafka生產(chǎn)者消費(fèi)者通過(guò)維護(hù)分區(qū)的偏移(或者說(shuō)索引)來(lái)順序的讀出消息，然后消費(fèi)消息。單個(gè)消費(fèi)者可以消費(fèi)多個(gè)不同的主題，并且消費(fèi)者的數(shù)量可以伸縮到可獲取的最大分區(qū)數(shù)量。所以在創(chuàng)建主題的時(shí)候，我們要認(rèn)真的考慮一下在創(chuàng)建的主題上預(yù)期的消息吞吐量。消費(fèi)同一個(gè)主題的多個(gè)消費(fèi)者構(gòu)成的組稱為消費(fèi)者組。通過(guò)Kafka提供的API可以處理同一消費(fèi)者組中多個(gè)消費(fèi)者之間的分區(qū)平衡以及消費(fèi)者當(dāng)前分區(qū)偏移的存儲(chǔ)。

Kafka消費(fèi)者Kafka實(shí)現(xiàn)的消息模式Kafka的實(shí)現(xiàn)很好地契合發(fā)布/訂閱模式。生產(chǎn)者可以向一個(gè)具體的主題發(fā)送消息，然后多個(gè)消費(fèi)者組可以消費(fèi)相同的消息。每一個(gè)消費(fèi)者組都可以獨(dú)立的伸縮去處理相應(yīng)的負(fù)載。由于消費(fèi)者維護(hù)自己的分區(qū)偏移，所以他們可以選擇持久訂閱或者臨時(shí)訂閱，持久訂閱在重啟之后不會(huì)丟失偏移而臨時(shí)訂閱在重啟之后會(huì)丟失偏移并且每次重啟之后都會(huì)從分區(qū)中最新的記錄開(kāi)始讀取。但是這種實(shí)現(xiàn)方案不能完全等價(jià)的當(dāng)做典型的消息隊(duì)列模式看待。當(dāng)然，我們可以創(chuàng)建一個(gè)主題，這個(gè)主題和擁有一個(gè)消費(fèi)者的消費(fèi)組進(jìn)行關(guān)聯(lián)，這樣我們就模擬出了一個(gè)典型的消息隊(duì)列。不過(guò)這會(huì)有許多缺點(diǎn)，我們會(huì)在第二部分詳細(xì)討論。值得特別注意的是，Kafka是按照預(yù)先配置好的時(shí)間保留分區(qū)中的消息，而不是根據(jù)消費(fèi)者是否消費(fèi)了這些消息。這種保留機(jī)制可以讓消費(fèi)者自由的重讀之前的消息。另外，開(kāi)發(fā)者也可以利用Kafka的存儲(chǔ)層來(lái)實(shí)現(xiàn)諸如事件溯源和日志審計(jì)功能。結(jié)束語(yǔ)

盡管有時(shí)候RabbitMQ和Kafka可以當(dāng)做等價(jià)來(lái)看，但是他們的實(shí)現(xiàn)是非常不同的。所以我們不能把他們當(dāng)做同種類(lèi)的工具來(lái)看待；一個(gè)是消息中間件，另一個(gè)是分布式流式系統(tǒng)。作為解決方案架構(gòu)師，我們要能夠認(rèn)識(shí)到它們之間的差異并且盡可能的考慮在給定場(chǎng)景中使用哪種類(lèi)型的解決方案。第二部分(未完成)會(huì)指出這些差異并且提供什么時(shí)候使用哪種方案的指導(dǎo)建議。原文鏈接：https://medium.com/better-programming/rabbitmq-vs-kafka-1ef22a041793文章來(lái)源：分布式實(shí)驗(yàn)室，點(diǎn)擊查看原文。▼往期精彩回顧▼Delayed Message 插件實(shí)現(xiàn) RabbitMQ 延遲隊(duì)列利用 RabbitMQ 死信隊(duì)列和 TTL 實(shí)現(xiàn)定時(shí)任務(wù)高并發(fā)場(chǎng)景下 RabbitMQ 消費(fèi)端服務(wù)限流實(shí)踐圖文實(shí)踐 RabbitMQ 不同類(lèi)型交換機(jī)消息投遞機(jī)制一次 RabbitMQ 生產(chǎn)故障引發(fā)的服務(wù)重連限流思考消息中間件 RabbitMQ 入門(mén)篇多維度分析 Express、Koa 之間的區(qū)別你需要了解的有關(guān) Node.js 的所有信息不容錯(cuò)過(guò)的 Node.js 項(xiàng)目架構(gòu)

總結(jié)

以上是生活随笔為你收集整理的rabbitmq 查看消费者_RabbitMQ 和 Kafka 的比较的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。