介紹

作為處理許多基于微服務(wù)的系統(tǒng)的軟件架構(gòu)師，我經(jīng)常遇到一個(gè)不斷重復(fù)的問(wèn)題："我應(yīng)該使用RabbitMQ還是Kafka？" 由于某些原因，許多開(kāi)發(fā)人員認(rèn)為這些技術(shù)是可互換的。 盡管在某些情況下確實(shí)如此，但這些平臺(tái)之間存在各種潛在的差異。

結(jié)果，不同的方案需要不同的解決方案，選擇錯(cuò)誤的方案可能會(huì)嚴(yán)重影響您設(shè)計(jì)，開(kāi)發(fā)和維護(hù)軟件解決方案的能力。

本文的目的是首先介紹基本的異步消息傳遞模式。 然后，它將繼續(xù)介紹RabbitMQ和Kafka及其內(nèi)部結(jié)構(gòu)。 第2部分將重點(diǎn)介紹這些平臺(tái)之間的關(guān)鍵區(qū)別，它們的各種優(yōu)缺點(diǎn)以及如何在兩者之間進(jìn)行選擇。

異步消息傳遞模式

異步消息傳遞是一種消息傳遞方案，其中生產(chǎn)者的消息生產(chǎn)與消費(fèi)者的消息處理不相關(guān)。 在處理消息傳遞系統(tǒng)時(shí)，我們通常會(huì)確定兩種主要的消息傳遞模式-消息排隊(duì)和發(fā)布/訂閱。

消息隊(duì)列

在消息隊(duì)列通信模式中，隊(duì)列在時(shí)間上使生產(chǎn)者與消費(fèi)者脫鉤。 多個(gè)生產(chǎn)者可以將消息發(fā)送到同一隊(duì)列。 但是，當(dāng)使用者處理郵件時(shí)，該郵件將被鎖定或從隊(duì)列中刪除，并且不再可用。 只有一個(gè)消費(fèi)者消費(fèi)一條特定的消息。

Message queuing

附帶說(shuō)明一下，如果使用者無(wú)法處理某條消息，則消息傳遞平臺(tái)通常會(huì)將消息返回到隊(duì)列中，以供其他使用者使用。 除了臨時(shí)解耦，隊(duì)列還使我們能夠獨(dú)立地?cái)U(kuò)展生產(chǎn)者和消費(fèi)者的規(guī)模，并提供一定程度的容錯(cuò)能力以應(yīng)對(duì)處理錯(cuò)誤。

發(fā)布/訂閱

在發(fā)布/訂閱（或pub / sub）通信模式中，多個(gè)訂戶(hù)可以同時(shí)接收和處理一條消息。

Publish/subscribe

例如，此模式允許發(fā)布者通知所有訂閱者系統(tǒng)中發(fā)生了某些事情。 許多排隊(duì)平臺(tái)通常將pub / sub與術(shù)語(yǔ)主題相關(guān)聯(lián)。 在RabbitMQ中，主題是pub / sub實(shí)現(xiàn)的一種特定類(lèi)型（確切地說(shuō)是一種交換類(lèi)型），但是在本篇文章中，我將主題稱(chēng)為pub / sub整體的表示。

一般而言，訂閱有兩種類(lèi)型：

· 臨時(shí)訂閱，僅在使用者啟動(dòng)并運(yùn)行時(shí)，訂閱才處于活動(dòng)狀態(tài)。 使用者關(guān)閉后，其訂閱和尚未處理的消息就會(huì)丟失。

· 長(zhǎng)期訂閱，只要未明確刪除訂閱，訂閱就會(huì)一直保留。 當(dāng)使用者關(guān)閉時(shí)，消息傳遞平臺(tái)將維護(hù)訂閱，并且稍后可以恢復(fù)消息處理。

RabbitMQ

RabbitMQ是消息代理的實(shí)現(xiàn)，通常稱(chēng)為服務(wù)總線(xiàn)。 它本身支持上述兩種消息傳遞模式。 消息代理的其他流行實(shí)現(xiàn)包括ActiveMQ，ZeroMQ，Azure服務(wù)總線(xiàn)和Amazon Simple Queue Service（SQS）。 所有這些實(shí)現(xiàn)都有很多共同點(diǎn)。 本文中描述的許多概念都適用于大多數(shù)概念。

消息隊(duì)列

RabbitMQ支持開(kāi)箱即用的經(jīng)典消息隊(duì)列。 開(kāi)發(fā)人員定義命名隊(duì)列，然后發(fā)布者可以將消息發(fā)送到該命名隊(duì)列。 消費(fèi)者進(jìn)而使用相同的隊(duì)列來(lái)檢索消息以對(duì)其進(jìn)行處理。

信息交流

RabbitMQ通過(guò)使用消息交換來(lái)實(shí)現(xiàn)pub / sub。 發(fā)布者將其消息發(fā)布到消息交換，而不知道這些消息的訂閱者是誰(shuí)。

每個(gè)希望訂閱交換的消費(fèi)者都會(huì)創(chuàng)建一個(gè)隊(duì)列。 然后，消息交換將產(chǎn)生的消息排隊(duì)，以供消費(fèi)者使用。 它還可以基于各種路由規(guī)則為某些訂戶(hù)過(guò)濾消息。

RabbitMQ message exchange

請(qǐng)務(wù)必注意，RabbitMQ支持臨時(shí)訂閱和持久訂閱。 消費(fèi)者可以通過(guò)RabbitMQ的API決定要使用的訂閱類(lèi)型。

由于RabbitMQ的體系結(jié)構(gòu)，我們還可以創(chuàng)建一種混合方法-一些訂戶(hù)形成消費(fèi)者組，這些消費(fèi)者組以特定隊(duì)列中競(jìng)爭(zhēng)的消費(fèi)者的形式一起處理消息。 通過(guò)這種方式，我們實(shí)現(xiàn)了發(fā)布/訂閱模式，同時(shí)還允許某些訂閱者擴(kuò)大規(guī)模以處理收到的消息。

Pub/sub and queuing combined

Apache Kafka

Apache Kafka不是消息代理的實(shí)現(xiàn)。 而是一個(gè)分布式流媒體平臺(tái)。

與基于隊(duì)列和交換的RabbitMQ不同，Kafka的存儲(chǔ)層是使用分區(qū)的事務(wù)日志實(shí)現(xiàn)的。 Kafka還提供用于實(shí)時(shí)處理流的Streams API和可輕松與各種數(shù)據(jù)源集成的Connector API。 但是，這些不在本文的討論范圍之內(nèi)。

云供應(yīng)商為Kafka的存儲(chǔ)層提供了替代解決方案。 這些解決方案包括Azure事件中心，在某種程度上還包括AWS Kinesis數(shù)據(jù)流。 Kafka的流處理功能也有特定于云的開(kāi)源替代方案，但是同樣，這些不在本文的討論范圍之內(nèi)。

話(huà)題 Topic

Kafka沒(méi)有實(shí)現(xiàn)隊(duì)列的概念。 相反，Kafka將記錄的集合存儲(chǔ)在稱(chēng)為主題的類(lèi)別中。

對(duì)于每個(gè)主題，Kafka維護(hù)消息的分區(qū)日志。 每個(gè)分區(qū)都是一個(gè)有序的，不可變的記錄序列，在該記錄中連續(xù)附加消息。

當(dāng)這些分區(qū)到達(dá)時(shí)，Kafka會(huì)將消息附加到這些分區(qū)。 默認(rèn)情況下，它使用循環(huán)分區(qū)程序在各個(gè)分區(qū)之間均勻分布消息。

生產(chǎn)者可以修改此行為以創(chuàng)建消息的邏輯流。 例如，在多租戶(hù)應(yīng)用程序中，我們可能想根據(jù)每個(gè)消息的租戶(hù)ID創(chuàng)建邏輯消息流。 在物聯(lián)網(wǎng)場(chǎng)景中，我們可能希望不斷將每個(gè)生產(chǎn)者的身份映射到特定分區(qū)。 確保來(lái)自同一邏輯流的所有消息都映射到同一分區(qū)，以確保將其傳遞給消費(fèi)者。

Kafka producers

使用者通過(guò)維持這些分區(qū)的偏移量（或索引）并順序讀取它們來(lái)消費(fèi)消息。

單個(gè)使用者可以使用多個(gè)主題，并且使用者可以擴(kuò)展到可用分區(qū)的數(shù)量。

因此，在創(chuàng)建主題時(shí)，應(yīng)仔細(xì)考慮該主題上消息傳遞的預(yù)期吞吐量。 一起工作以消費(fèi)主題的一組消費(fèi)者稱(chēng)為消費(fèi)群體。 Kafka的API通常會(huì)處理消費(fèi)者組中消費(fèi)者之間的分區(qū)處理與消費(fèi)者當(dāng)前分區(qū)偏移量的存儲(chǔ)之間的平衡。

Kafka consumers

使用Kafka實(shí)現(xiàn)消息傳遞模式

Kafka的實(shí)現(xiàn)非常適合pub / sub模式。

生產(chǎn)者可以將消息發(fā)送到特定主題，而多個(gè)消費(fèi)者組可以使用同一條消息。 每個(gè)消費(fèi)者組可以單獨(dú)擴(kuò)展以處理負(fù)載。 由于使用者維護(hù)其分區(qū)偏移量，因此他們可以選擇具有持久性的訂閱，該持久性訂閱在重新啟動(dòng)或臨時(shí)訂閱期間保持其偏移量，這將丟棄偏移量，并在每次啟動(dòng)時(shí)從每個(gè)分區(qū)中的最新記錄重新啟動(dòng)。

但是，它不適用于消息隊(duì)列模式。 當(dāng)然，我們可以只包含一個(gè)消費(fèi)者組來(lái)模擬一個(gè)經(jīng)典消息隊(duì)列。 然而，這有多個(gè)缺點(diǎn)。本文的第2部分將詳細(xì)討論。

請(qǐng)務(wù)必注意，Kafka會(huì)將郵件保留在分區(qū)中，直到預(yù)定的時(shí)間，無(wú)論消費(fèi)者是否消費(fèi)了這些郵件。 這種保留意味著消費(fèi)者可以自由地重讀過(guò)去的消息。 此外，開(kāi)發(fā)人員還可以使用Kafka的存儲(chǔ)層來(lái)實(shí)現(xiàn)各種機(jī)制，例如事件源和審核日志。

進(jìn)一步閱讀

如果您想了解有關(guān)RabbitMQ和Kafka的內(nèi)部實(shí)現(xiàn)的更多信息，我建議您使用以下資源：

· AMQP 0.9.1模型解釋— RabbitMQ

· Apache Kafka簡(jiǎn)介

結(jié)束語(yǔ)

盡管RabbitMQ和Kafka有時(shí)可以互換，但是它們的實(shí)現(xiàn)卻有很大的不同。 因此，我們無(wú)法將它們視為同一類(lèi)工具的成員； 一個(gè)是消息代理，另一個(gè)是分布式流平臺(tái)。

作為解決方案架構(gòu)師，我們應(yīng)該承認(rèn)這些差異，并積極考慮在給定場(chǎng)景下應(yīng)使用哪種類(lèi)型的解決方案。 第2部分解決了這些差異，并提供了何時(shí)使用它們的指南。