作為一個(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和Apache Kafka內(nèi)部實(shí)現(xiàn)的相關(guān)概念。緊接著會(huì)主要介紹這兩種技術(shù)的主要不同點(diǎn)以及他們各自的優(yōu)缺點(diǎn)，最后我們會(huì)說(shuō)明一下怎樣選擇這兩種技術(shù)。

異步消息可以作為解耦消息的生產(chǎn)和處理的一種解決方案。提到消息系統(tǒng)，我們通常會(huì)想到兩種主要的消息模式——消息隊(duì)列和發(fā)布/訂閱模式。

利用消息隊(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ā)布/訂閱（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ō)，訂閱有兩種類型：

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

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

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)有許多共通的地方，這邊文章中提到的許多概念大部分都適用于這些中間件。

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í)和持久兩種訂閱類型。消費(fèi)者可以調(diào)用RabbitMQ的API來(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不是消息中間件的一種實(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按照類別存儲(chǔ)記錄集，并且把這種類別稱為主題。

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)很好地契合發(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ì)功能。

作為解決方案架構(gòu)師，我們要能夠認(rèn)識(shí)到它們之間的差異并且盡可能的考慮在給定場(chǎng)景中使用哪種類型的解決方案。下面會(huì)指出這些差異并且提供什么時(shí)候使用哪種方案的指導(dǎo)建議。

RabbitMQ是一個(gè)消息代理，但是Apache Kafka是一個(gè)分布式流式系統(tǒng)。好像從語(yǔ)義上就可以看出差異，但是它們內(nèi)部的一些特性會(huì)影響到我們是否能夠很好的設(shè)計(jì)各種用例。

例如，Kafka最適用于數(shù)據(jù)的流式處理，但是RabbitMQ對(duì)流式中的消息就很難保持它們的順序。

另一方面，RabbitMQ內(nèi)置重試邏輯和死信（dead-letter）交換器，但是Kafka只是把這些實(shí)現(xiàn)邏輯交給用戶來(lái)處理。

這部分主要強(qiáng)調(diào)在不同系統(tǒng)之間它們的主要差異。

對(duì)于發(fā)送到隊(duì)列或者交換器上的消息，RabbitMQ不保證它們的順序。盡管消費(fèi)者按照順序處理生產(chǎn)者發(fā)來(lái)的消息看上去很符合邏輯，但是這有很大誤導(dǎo)性。

RabbitMQ文檔中有關(guān)于消息順序保證的說(shuō)明：

換話句話說(shuō)，只要我們是單個(gè)消費(fèi)者，那么接收到的消息就是有序的。然而，一旦有多個(gè)消費(fèi)者從同一個(gè)隊(duì)列中讀取消息，那么消息的處理順序就沒(méi)法保證了。

由于消費(fèi)者讀取消息之后可能會(huì)把消息放回（或者重傳）到隊(duì)列中（例如，處理失敗的情況），這樣就會(huì)導(dǎo)致消息的順序無(wú)法保證。

一旦一個(gè)消息被重新放回隊(duì)列，另一個(gè)消費(fèi)者可以繼續(xù)處理它，即使這個(gè)消費(fèi)者已經(jīng)處理到了放回消息之后的消息。因此，消費(fèi)者組處理消息是無(wú)序的，如下表所示：

使用RabbitMQ丟失消息順序的例子

當(dāng)然，我們可以通過(guò)限制消費(fèi)者的并發(fā)數(shù)等于1來(lái)保證RabbitMQ中的消息有序性。更準(zhǔn)確點(diǎn)說(shuō)，限制單個(gè)消費(fèi)者中的線程數(shù)為1，因?yàn)槿魏蔚牟⑿邢⑻幚矶紩?huì)導(dǎo)致無(wú)序問(wèn)題。

不過(guò)，隨著系統(tǒng)規(guī)模增長(zhǎng)，單線程消費(fèi)者模式會(huì)嚴(yán)重影響消息處理能力。所以，我們不要輕易的選擇這種方案。

另一方面，對(duì)于Kafka來(lái)說(shuō)，它在消息處理方面提供了可靠的順序保證。Kafka能夠保證發(fā)送到相同主題分區(qū)的所有消息都能夠按照順序處理。

在前面說(shuō)過(guò)，默認(rèn)情況下，Kafka會(huì)使用循環(huán)分區(qū)器（round-robin partitioner）把消息放到相應(yīng)的分區(qū)上。不過(guò)，生產(chǎn)者可以給每個(gè)消息設(shè)置分區(qū)鍵（key）來(lái)創(chuàng)建數(shù)據(jù)邏輯流（比如來(lái)自同一個(gè)設(shè)備的消息，或者屬于同一租戶的消息）。

所有來(lái)自相同流的消息都會(huì)被放到相同的分區(qū)中，這樣消費(fèi)者組就可以按照順序處理它們。

但是，我們也應(yīng)該注意到，在同一個(gè)消費(fèi)者組中，每個(gè)分區(qū)都是由一個(gè)消費(fèi)者的一個(gè)線程來(lái)處理。結(jié)果就是我們沒(méi)法伸縮（scale）單個(gè)分區(qū)的處理能力。

不過(guò)，在Kafka中，我們可以伸縮一個(gè)主題中的分區(qū)數(shù)量，這樣可以讓每個(gè)分區(qū)分擔(dān)更少的消息，然后增加更多的消費(fèi)者來(lái)處理額外的分區(qū)。

獲勝者（Winner）：

顯而易見(jiàn)，Kafka是獲勝者，因?yàn)樗梢员ＷC按順序處理消息。RabbitMQ在這塊就相對(duì)比較弱。

RabbitMQ可以基于定義的訂閱者路由規(guī)則路由消息給一個(gè)消息交換器上的訂閱者。一個(gè)主題交換器可以通過(guò)一個(gè)叫做routing_key的特定頭來(lái)路由消息。

或者，一個(gè)頭部（headers）交換器可以基于任意的消息頭來(lái)路由消息。這兩種交換器都能夠有效地讓消費(fèi)者設(shè)置他們感興趣的消息類型，因此可以給解決方案架構(gòu)師提供很好的靈活性。

另一方面，Kafka在處理消息之前是不允許消費(fèi)者過(guò)濾一個(gè)主題中的消息。一個(gè)訂閱的消費(fèi)者在沒(méi)有異常情況下會(huì)接受一個(gè)分區(qū)中的所有消息。

作為一個(gè)開(kāi)發(fā)者，你可能使用Kafka流式作業(yè)（job），它會(huì)從主題中讀取消息，然后過(guò)濾，最后再把過(guò)濾的消息推送到另一個(gè)消費(fèi)者可以訂閱的主題。但是，這需要更多的工作量和維護(hù)，并且還涉及到更多的移動(dòng)操作。

獲勝者：

在消息路由和過(guò)濾方面，RabbitMQ提供了更好的支持。

在測(cè)定發(fā)送到一個(gè)隊(duì)列的消息時(shí)間方面，RabbitMQ提供了多種能力：

1）消息存活時(shí)間（TTL）

發(fā)送到RabbitMQ的每條消息都可以關(guān)聯(lián)一個(gè)TTL屬性。發(fā)布者可以直接設(shè)置TTL或者根據(jù)隊(duì)列的策略來(lái)設(shè)置。

系統(tǒng)可以根據(jù)設(shè)置的TTL來(lái)限制消息的有效期。如果消費(fèi)者在預(yù)期時(shí)間內(nèi)沒(méi)有處理該消息，那么這條消息會(huì)自動(dòng)的從隊(duì)列上被移除（并且會(huì)被移到死信交換器上，同時(shí)在這之后的消息都會(huì)這樣處理）。

TTL對(duì)于那些有時(shí)效性的命令特別有用，因?yàn)橐欢螘r(shí)間內(nèi)沒(méi)有處理的話，這些命令就沒(méi)有什么意義了。

2）延遲/預(yù)定的消息

RabbitMQ可以通過(guò)插件的方式來(lái)支持延遲或者預(yù)定的消息。當(dāng)這個(gè)插件在消息交換器上啟用的時(shí)候，生產(chǎn)者可以發(fā)送消息到RabbitMQ上，然后這個(gè)生產(chǎn)者可以延遲RabbitMQ路由這個(gè)消息到消費(fèi)者隊(duì)列的時(shí)間。

這個(gè)功能允許開(kāi)發(fā)者調(diào)度將來(lái)（future）的命令，也就是在那之前不應(yīng)該被處理的命令。例如，當(dāng)生產(chǎn)者遇到限流規(guī)則時(shí)，我們可能會(huì)把這些特定的命令延遲到之后的一個(gè)時(shí)間執(zhí)行。

Kafka沒(méi)有提供這些功能。它在消息到達(dá)的時(shí)候就把它們寫(xiě)入分區(qū)中，這樣消費(fèi)者就可以立即獲取到消息去處理。

Kafka也沒(méi)用為消息提供TTL的機(jī)制，不過(guò)我們可以在應(yīng)用層實(shí)現(xiàn)。

不過(guò)，我們必須要記住的一點(diǎn)是Kafka分區(qū)是一種追加模式的事務(wù)日志。所以，它是不能處理消息時(shí)間（或者分區(qū)中的位置）。

獲勝者：

毫無(wú)疑問(wèn)，RabbitMQ是獲勝者，因?yàn)檫@種實(shí)現(xiàn)天然的就限制Kafka。

當(dāng)消費(fèi)者成功消費(fèi)消息之后，RabbitMQ就會(huì)把對(duì)應(yīng)的消息從存儲(chǔ)中刪除。這種行為沒(méi)法修改。它幾乎是所有消息代理設(shè)計(jì)的必備部分。

相反，Kafka會(huì)給每個(gè)主題配置超時(shí)時(shí)間，只要沒(méi)有達(dá)到超時(shí)時(shí)間的消息都會(huì)保留下來(lái)。在消息留存方面，Kafka僅僅把它當(dāng)做消息日志來(lái)看待，并不關(guān)心消費(fèi)者的消費(fèi)狀態(tài)。

消費(fèi)者可以不限次數(shù)的消費(fèi)每條消息，并且他們可以操作分區(qū)偏移來(lái)“及時(shí)”往返的處理這些消息。Kafka會(huì)周期的檢查分區(qū)中消息的留存時(shí)間，一旦消息超過(guò)設(shè)定保留的時(shí)長(zhǎng)，就會(huì)被刪除。

Kafka的性能不依賴于存儲(chǔ)大小。所以，理論上，它存儲(chǔ)消息幾乎不會(huì)影響性能（只要你的節(jié)點(diǎn)有足夠多的空間保存這些分區(qū)）。

獲勝者：

Kafka設(shè)計(jì)之初就是保存消息的，但是RabbitMQ并不是。所以這塊沒(méi)有可比性，Kafka是獲勝者。

當(dāng)處理消息，隊(duì)列和事件時(shí)，開(kāi)發(fā)者常常認(rèn)為消息處理總是成功的。畢竟，生產(chǎn)者把每條消息放入隊(duì)列或者主題后，即使消費(fèi)者處理消息失敗了，它僅僅需要做的就是重新嘗試，直到成功為止。

盡管表面上看這種方法是沒(méi)錯(cuò)的，但是我們應(yīng)該對(duì)這種處理方式多思考一下。首先我們應(yīng)該承認(rèn)，在某些場(chǎng)景下，消息處理會(huì)失敗。所以，即使在解決方案部分需要人為干預(yù)的情況下，我們也要妥善地處理這些情況。

消息處理存在兩種可能的故障：

1）瞬時(shí)故障——故障產(chǎn)生是由于臨時(shí)問(wèn)題導(dǎo)致，比如網(wǎng)絡(luò)連接，CPU負(fù)載，或者服務(wù)崩潰。我們可以通過(guò)一遍又一遍的嘗試來(lái)減輕這種故障。

2）持久故障——故障產(chǎn)生是由于永久的問(wèn)題導(dǎo)致的，并且這種問(wèn)題不能通過(guò)額外的重試來(lái)解決。比如常見(jiàn)的原因有軟件bug或者無(wú)效的消息格式（例如，損壞（poison）的消息）。

作為架構(gòu)師和開(kāi)發(fā)者，我們應(yīng)該問(wèn)問(wèn)自己：“對(duì)于消息處理故障，我們應(yīng)該重試多少次？每一次重試之間我們應(yīng)該等多久？我們?cè)鯓訁^(qū)分瞬時(shí)和持久故障？”

最重要的是：“所有重試都失敗后或者遇到一個(gè)持久的故障，我們要做什么？”

當(dāng)然，不同業(yè)務(wù)領(lǐng)域有不同的回答，消息系統(tǒng)一般會(huì)給我們提供工具讓我們自己實(shí)現(xiàn)解決方案。

RabbitMQ會(huì)給我們提供諸如交付重試和死信交換器（DLX）來(lái)處理消息處理故障。

DLX的主要思路是根據(jù)合適的配置信息自動(dòng)地把路由失敗的消息發(fā)送到DLX，并且在交換器上根據(jù)規(guī)則來(lái)進(jìn)一步的處理，比如異常重試，重試計(jì)數(shù)以及發(fā)送到“人為干預(yù)”的隊(duì)列。

查看下面篇文章，它在RabbitMQ處理重試上提供了額外的可能模式視角。

鏈接：https://engineering.nanit.com/rabbitmq-retries-the-full-story-ca4cc6c5b493

在RabbitMQ中我們需要記住最重要的事情是當(dāng)一個(gè)消費(fèi)者正在處理或者重試某個(gè)消息時(shí)（即使是在把它返回隊(duì)列之前），其他消費(fèi)者都可以并發(fā)的處理這個(gè)消息之后的其他消息。

當(dāng)某個(gè)消費(fèi)者在重試處理某條消息時(shí)，作為一個(gè)整體的消息處理邏輯不會(huì)被阻塞。所以，一個(gè)消費(fèi)者可以同步地去重試處理一條消息，不管花費(fèi)多長(zhǎng)時(shí)間都不會(huì)影響整個(gè)系統(tǒng)的運(yùn)行。

消費(fèi)者1持續(xù)的在重試處理消息1，同時(shí)其他消費(fèi)者可以繼續(xù)處理其他消息

和RabbitMQ相反，Kafka沒(méi)有提供這種開(kāi)箱即用的機(jī)制。在Kafka中，需要我們自己在應(yīng)用層提供和實(shí)現(xiàn)消息重試機(jī)制。

另外，我們需要注意的是當(dāng)一個(gè)消費(fèi)者正在同步地處理一個(gè)特定的消息時(shí)，那么同在這個(gè)分區(qū)上的其他消息是沒(méi)法被處理的。

由于消費(fèi)者不能改變消息的順序，所以我們不能夠拒絕和重試一個(gè)特定的消息以及提交一個(gè)在這個(gè)消息之后的消息。你只要記住，分區(qū)僅僅是一個(gè)追加模式的日志。

一個(gè)應(yīng)用層解決方案可以把失敗的消息提交到一個(gè)“重試主題”，并且從那個(gè)主題中處理重試；但是這樣的話我們就會(huì)丟失消息的順序。

我們可以在Uber.com上找到Uber工程師實(shí)現(xiàn)的一個(gè)例子。如果消息處理的時(shí)延不是關(guān)注點(diǎn)，那么對(duì)錯(cuò)誤有足夠監(jiān)控的Kafka方案可能就足夠了。

如果消費(fèi)者阻塞在重試一個(gè)消息上，那么底部分區(qū)的消息就不會(huì)被處理

獲勝者：

RabbitMQ是獲勝者，因?yàn)樗峁┝艘粋€(gè)解決這個(gè)問(wèn)題的開(kāi)箱即用的機(jī)制。

有多個(gè)基準(zhǔn)測(cè)試，用于檢查RabbitMQ和Kafka的性能。

盡管通用的基準(zhǔn)測(cè)試對(duì)一些特定的情況會(huì)有限制，但是Kafka通常被認(rèn)為比RabbitMQ有更優(yōu)越的性能。

Kafka使用順序磁盤(pán)I / O來(lái)提高性能。

從Kafka使用分區(qū)的架構(gòu)上看，它在橫向擴(kuò)展上會(huì)優(yōu)于RabbitMQ，當(dāng)然RabbitMQ在縱向擴(kuò)展上會(huì)有更多的優(yōu)勢(shì)。

Kafka的大規(guī)模部署通常每秒可以處理數(shù)十萬(wàn)條消息，甚至每秒百萬(wàn)級(jí)別的消息。

過(guò)去，Pivotal記錄了一個(gè)Kafka集群每秒處理一百萬(wàn)條消息的例子；但是，它是在一個(gè)有著30個(gè)節(jié)點(diǎn)集群上做的，并且這些消息負(fù)載被優(yōu)化分散到多個(gè)隊(duì)列和交換器上。

鏈接：https://content.pivotal.io/blog/rabbitmq-hits-one-million-messages-per-second-on-google-compute-engine

典型的RabbitMQ部署包含3到7個(gè)節(jié)點(diǎn)的集群，并且這些集群也不需要把負(fù)載分散到不同的隊(duì)列上。這些典型的集群通?？梢灶A(yù)期每秒處理幾萬(wàn)條消息。

獲勝者：

盡管這兩個(gè)消息平臺(tái)都可以處理大規(guī)模負(fù)載，但是Kafka在伸縮方面更優(yōu)并且能夠獲得比RabbitMQ更高的吞吐量，因此這局Kafka獲勝。

但是，值得注意的是大部分系統(tǒng)都還沒(méi)有達(dá)到這些極限！所以，除非你正在構(gòu)建下一個(gè)非常受歡迎的百萬(wàn)級(jí)用戶軟件系統(tǒng)，否則你不需要太關(guān)心伸縮性問(wèn)題，畢竟這兩個(gè)消息平臺(tái)都可以工作的很好。

RabbitMQ使用的是智能代理和傻瓜式消費(fèi)者模式。消費(fèi)者注冊(cè)到消費(fèi)者隊(duì)列，然后RabbitMQ把傳進(jìn)來(lái)的消息推送給消費(fèi)者。RabbitMQ也有拉?。╬ull）API；不過(guò)，一般很少被使用。

RabbitMQ管理消息的分發(fā)以及隊(duì)列上消息的移除（也可能轉(zhuǎn)移到DLX）。消費(fèi)者不需要考慮這塊。

根據(jù)RabbitMQ結(jié)構(gòu)的設(shè)計(jì)，當(dāng)負(fù)載增加的時(shí)候，一個(gè)隊(duì)列上的消費(fèi)者組可以有效的從僅僅一個(gè)消費(fèi)者擴(kuò)展到多個(gè)消費(fèi)者，并且不需要對(duì)系統(tǒng)做任何的改變。

RabbitMQ高效的伸縮

相反，Kafka使用的是傻瓜式代理和智能消費(fèi)者模式。消費(fèi)者組中的消費(fèi)者需要協(xié)調(diào)他們之間的主題分區(qū)租約（以便一個(gè)具體的分區(qū)只由消費(fèi)者組中一個(gè)消費(fèi)者監(jiān)聽(tīng)）。

消費(fèi)者也需要去管理和存儲(chǔ)他們分區(qū)偏移索引。幸運(yùn)的是Kafka SDK已經(jīng)為我們封裝了，所以我們不需要自己管理。

另外，當(dāng)我們有一個(gè)低負(fù)載時(shí)，單個(gè)消費(fèi)者需要處理并且并行的管理多個(gè)分區(qū)，這在消費(fèi)者端會(huì)消耗更多的資源。

當(dāng)然，隨著負(fù)載增加，我們只需要伸縮消費(fèi)者組使其消費(fèi)者的數(shù)量等于主題中分區(qū)的數(shù)量。這就需要我們配置Kafka增加額外的分區(qū)。

但是，隨著負(fù)載再次降低，我們不能移除我們之前增加的分區(qū)，這需要給消費(fèi)者增加更多的工作量。盡管這樣，但是正如我們上面提到過(guò)，Kafka SDK已經(jīng)幫我們做了這個(gè)額外的工作。

Kafka分區(qū)沒(méi)法移除，向下伸縮后消費(fèi)者會(huì)做更多的工作

獲勝者：

根據(jù)設(shè)計(jì)，RabbitMQ就是為了傻瓜式消費(fèi)者而構(gòu)建的。所以這輪RabbitMQ獲勝。

現(xiàn)在我們就如面對(duì)百萬(wàn)美元問(wèn)題一樣：“什么時(shí)候使用RabbitMQ以及什么時(shí)候使用Kafka？”概括上面的差異，我們不難得出下面的結(jié)論。

優(yōu)先選擇RabbitMQ的條件：

優(yōu)先選擇Kafka的條件：

大部分情況下這兩個(gè)消息平臺(tái)都可以滿足我們的要求。但是，它取決于我們的架構(gòu)師，他們會(huì)選擇最合適的工具。當(dāng)做決策的時(shí)候，我們需要考慮上面著重強(qiáng)調(diào)的功能性差異和非功能性限制。

這些限制如下：

當(dāng)開(kāi)發(fā)復(fù)雜的軟件系統(tǒng)時(shí)，我們可能被誘導(dǎo)使用同一個(gè)消息平臺(tái)去實(shí)現(xiàn)所有必須的消息用例。但是，從我的經(jīng)驗(yàn)看，通常同時(shí)使用這兩個(gè)消息平臺(tái)能夠帶來(lái)更多的好處。

例如，在一個(gè)事件驅(qū)動(dòng)的架構(gòu)系統(tǒng)中，我們可以使用RabbitMQ在服務(wù)之間發(fā)送命令，并且使用Kafka實(shí)現(xiàn)業(yè)務(wù)事件通知。

原因是事件通知常常用于事件溯源，批量操作（ETL風(fēng)格），或者審計(jì)目的，因此Kafka的消息留存能力就顯得很有價(jià)值。

相反，命令一般需要在消費(fèi)者端做額外處理，并且處理可以失敗，所以需要高級(jí)的容錯(cuò)處理能力。

這里，RabbitMQ在功能上有很多閃光點(diǎn)。以后我可能會(huì)寫(xiě)一篇詳細(xì)的文章來(lái)介紹，但是你必須記住--你的里程（mileage）可能會(huì)變化，因?yàn)檫m合性取決于你的特定需求。

寫(xiě)這篇文章是由于我觀察到許多開(kāi)發(fā)者把這RabbitMQ和Kafka作為等價(jià)來(lái)看待。我希望通過(guò)這篇文章的幫助能夠讓你獲得對(duì)這兩種技術(shù)實(shí)現(xiàn)的深刻理解以及它們之間的技術(shù)差異。

反過(guò)來(lái)通過(guò)它們之間的差異來(lái)影響這兩個(gè)平臺(tái)去給用例提供更好的服務(wù)。這兩個(gè)消息平臺(tái)都很棒，并且都能夠給多個(gè)用例提供很好的服務(wù)。

但是，作為解決方案架構(gòu)師，取決于我們對(duì)每一個(gè)用例需求的理解，以及優(yōu)化，然后選擇最合適的解決方案。