Redis、Kafka或RabbitMQ，哪個(gè)更和微服務(wù)更般配？
作者：otonomo
來(lái)源：https://www.jdon.com/55161
將異步通信用于微服務(wù)時(shí)，通常使用消息代理。代理確保不同微服務(wù)之間的通信可靠且穩(wěn)定，確保消息在系統(tǒng)內(nèi)得到管理和監(jiān)視，并且消息不會(huì)丟失。您可以選擇一些消息代理，它們的規(guī)模和數(shù)據(jù)功能各不相同。這篇博客文章將比較三種最受歡迎的經(jīng)紀(jì)人：RabbitMQ，Kafka和Redis。
但是首先，讓我們了解微服務(wù)通信。
微服務(wù)通信：同步和異步
微服務(wù)之間有兩種常見(jiàn)的通信方式：同步和異步。在同步通信中，調(diào)用方在發(fā)送下一條消息之前等待響應(yīng)，并且它作為HTTP之上的REST協(xié)議運(yùn)行。相反，在異步通信中，無(wú)需等待響應(yīng)即可發(fā)送消息。這適用于分布式系統(tǒng)，通常需要消息代理來(lái)管理消息。
您選擇的通信類型應(yīng)考慮不同的參數(shù)，例如微服務(wù)的結(jié)構(gòu)方式，適當(dāng)?shù)幕A(chǔ)架構(gòu)，延遲，規(guī)模，依賴關(guān)系以及通信目的。異步通信的建立可能會(huì)更加復(fù)雜，并且需要添加更多組件才能堆疊，但是將異步通信用于微服務(wù)的好處遠(yuǎn)大于缺點(diǎn)。
異步通訊的優(yōu)勢(shì)
首先，根據(jù)定義，異步通信是非阻塞的。它也支持比同步操作更好的縮放。第三，在微服務(wù)崩潰的情況下，異步通信機(jī)制提供了各種恢復(fù)技術(shù)，通常更擅長(zhǎng)處理與崩潰有關(guān)的錯(cuò)誤。另外，當(dāng)使用代理而不是REST協(xié)議時(shí)，接收通信的服務(wù)實(shí)際上并不需要彼此了解。在舊的服務(wù)運(yùn)行了很長(zhǎng)時(shí)間之后，甚至可以引入新的服務(wù)，即更好的解耦服務(wù)。
最后，在選擇異步操作時(shí)，您將增強(qiáng)將來(lái)創(chuàng)建集中發(fā)現(xiàn)，監(jiān)視，負(fù)載平衡甚至策略執(zhí)行器的能力。這將為您提供在代碼和系統(tǒng)構(gòu)建中具有靈活性，可伸縮性和更多功能的功能。
選擇合適的消息代理
異步通信通常通過(guò)消息代理進(jìn)行管理。也有其他方法，例如aysncio，但它們更加稀少和有限。
在選擇代理執(zhí)行異步操作時(shí)，應(yīng)考慮以下幾點(diǎn)：
代理規(guī)模–系統(tǒng)中每秒發(fā)送的消息數(shù)。 數(shù)據(jù)持久性–恢復(fù)消息的能力。 消費(fèi)者能力–經(jīng)紀(jì)人是否有能力管理一對(duì)一和/或一對(duì)多的消費(fèi)者。
一對(duì)一
一對(duì)多
我們檢查了那里最新和最出色的服務(wù)，以找出這三個(gè)類別中最強(qiáng)的提供商。
RabbitMQ（AMQP）
規(guī)模：根據(jù)配置和資源，這里的運(yùn)行速度約為每秒50K msg。
持久性：支持持久性消息和瞬時(shí)消息。
一對(duì)一與一對(duì)多的消費(fèi)者：兩者都有。
RabbitMQ于2007年發(fā)布，是最早創(chuàng)建的常見(jiàn)消息代理之一。它是一個(gè)開(kāi)放源代碼，通過(guò)實(shí)現(xiàn)高級(jí)消息隊(duì)列協(xié)議（AMQP）通過(guò)點(diǎn)對(duì)點(diǎn)和pub-sub方法傳遞消息。它旨在支持復(fù)雜的路由邏輯。
有一些托管服務(wù)可讓您將其用作SaaS，但它不是本機(jī)主要云提供商堆棧的一部分。RabbitMQ支持所有主要語(yǔ)言，包括Python，Java，.NET，PHP，Ruby，JavaScript，Go，Swift等。
在持久模式下，可能會(huì)遇到一些性能問(wèn)題。
kafka
規(guī)模：每秒最多可以發(fā)送一百萬(wàn)條消息。
持久性：是的。
一對(duì)一vs一對(duì)多的消費(fèi)者：只有一對(duì)多（乍一看似乎很奇怪，對(duì)吧？！）。
Kafka由Linkedin于2011年創(chuàng)建，旨在處理高吞吐量，低延遲的處理。作為一個(gè)分布式流平臺(tái)，Kafka復(fù)制了一個(gè)發(fā)布-訂閱服務(wù)。它提供數(shù)據(jù)持久性并存儲(chǔ)記錄流，使其能夠交換高質(zhì)量消息。
Kafka曾在Azure，AWS和Confluent上管理SaaS。他們都是Kafka項(xiàng)目的創(chuàng)建者和主要貢獻(xiàn)者。Kafka支持所有主要語(yǔ)言，包括Python，Java，C / C ++，Clojure，.NET，PHP，Ruby，JavaScript，Go，Swift等。
Redis
規(guī)模：每秒最多可以發(fā)送一百萬(wàn)條消息。
持久性：基本上不是，它是內(nèi)存中的數(shù)據(jù)存儲(chǔ)。
一對(duì)一與一對(duì)多的消費(fèi)者：兩者都有。
Redis與其他消息代理有點(diǎn)不同。Redis的核心是一個(gè)內(nèi)存中的數(shù)據(jù)存儲(chǔ)，可以用作高性能鍵值存儲(chǔ)或消息代理。另一個(gè)區(qū)別是Redis沒(méi)有持久性，而是將其內(nèi)存轉(zhuǎn)儲(chǔ)到Disk / DB中。它還非常適合實(shí)時(shí)數(shù)據(jù)處理。
最初，Redis不是一對(duì)一和一對(duì)多的。但是，由于Redis 5.0引入了pub-sub，因此功能得到了增強(qiáng)，一對(duì)多成為真正的選擇。
每個(gè)用例的消息代理
我們介紹了RabbitMQ，Kafka和Redis的一些特征。這三種動(dòng)物都是它們的類別，但是如上所述，它們的運(yùn)行方式大不相同。這是我們建議正確的消息代理根據(jù)不同用例使用的建議。
短命消息：Redis
Redis的內(nèi)存數(shù)據(jù)庫(kù)幾乎適用于不需要持久性的消息短暫的用例。因?yàn)镽edis提供了非?？焖俚姆?wù)和內(nèi)存功能，所以它是短保留消息的理想選擇，在這些消息中持久性不是很重要，您可以容忍一些丟失。隨著5.0中Redis流的發(fā)布，它也成為了一對(duì)多用例的候選者，由于局限性和舊的pub-sub功能，絕對(duì)需要使用它。
大量數(shù)據(jù)：Kafka
Kafka是一個(gè)高吞吐量的分布式隊(duì)列，用于長(zhǎng)時(shí)間存儲(chǔ)大量數(shù)據(jù)。對(duì)于需要持久性的一對(duì)多用例，Kafka是理想的選擇。
復(fù)雜路由：RabbitMQ
RabbitMQ是一個(gè)較老但很成熟的代理，具有許多支持復(fù)雜路由的功能。當(dāng)所需速率不高（超過(guò)數(shù)萬(wàn)msg / sec）時(shí)，它甚至將支持復(fù)雜的路由通信。
考慮您的軟件堆棧
當(dāng)然，最后要考慮的是您當(dāng)前的軟件堆棧。如果您正在尋找一個(gè)相對(duì)簡(jiǎn)單的集成過(guò)程，并且不想在堆棧中維護(hù)其他代理，那么您可能更傾向于使用已由堆棧支持的代理。
例如，如果您在RabbitMQ之上的系統(tǒng)中使用Celery for Task Queue，那么您會(huì)獲得與RabbitMQ或Redis一起使用的動(dòng)力，而不是不支持Kafka且需要進(jìn)行一些重寫(xiě)的Kafka。
我們通過(guò)平臺(tái)的發(fā)展和壯大使用了以上所有內(nèi)容，然后再進(jìn)行一些使用！重要的是要記住，每種工具都有自己的優(yōu)點(diǎn)和缺點(diǎn)，這與了解它們并為工作以及特定的時(shí)機(jī)，情況和要求選擇合適的工具有關(guān)。
好文章，我在看
