Redis、Kafka或RabbitMQ中哪個更和微服務更般配

但是首先，讓我們了解微服務通信。

微服務通信：同步和異步

微服務之間有兩種常見的通信方式：同步和異步。在同步通信中，調用方在發(fā)送下一條消息之前等待響應，并且它作為HTTP之上的REST協(xié)議運行。相反，在異步通信中，無需等待響應即可發(fā)送消息。這適用于分布式系統(tǒng)，通常需要消息代理來管理消息。

您選擇的通信類型應考慮不同的參數(shù)，例如微服務的結構方式，適當?shù)幕A架構，延遲，規(guī)模，依賴關系以及通信目的。異步通信的建立可能會更加復雜，并且需要添加更多組件才能堆疊，但是將異步通信用于微服務的好處遠大于缺點。

異步通訊的優(yōu)勢

首先，根據(jù)定義，異步通信是非阻塞的。它也支持比同步操作更好的縮放。第三，在微服務崩潰的情況下，異步通信機制提供了各種恢復技術，通常更擅長處理與崩潰有關的錯誤。另外，當使用代理而不是REST協(xié)議時，接收通信的服務實際上并不需要彼此了解。在舊的服務運行了很長時間之后，甚至可以引入新的服務，即更好的解耦服務。

最后，在選擇異步操作時，您將增強將來創(chuàng)建集中發(fā)現(xiàn)，監(jiān)視，負載平衡甚至策略執(zhí)行器的能力。這將為您提供在代碼和系統(tǒng)構建中具有靈活性，可伸縮性和更多功能的功能。

選擇合適的消息代理

異步通信通常通過消息代理進行管理。也有其他方法，例如aysncio，但它們更加稀少和有限。

在選擇代理執(zhí)行異步操作時，應考慮以下幾點：

1. 代理規(guī)模–系統(tǒng)中每秒發(fā)送的消息數(shù)。
2. 數(shù)據(jù)持久性–恢復消息的能力。
3. 消費者能力–經紀人是否有能力管理一對一和/或一對多的消費者。

一對一

 

一對多

 

我們檢查了那里最新和最出色的服務，以找出這三個類別中最強的提供商。

RabbitMQ（AMQP）

規(guī)模：根據(jù)配置和資源，這里的運行速度約為每秒50K msg。

持久性：支持持久性消息和瞬時消息。

一對一與一對多的消費者：兩者都有。

RabbitMQ于2007年發(fā)布，是最早創(chuàng)建的常見消息代理之一。它是一個開放源代碼，通過實現(xiàn)高級消息隊列協(xié)議（AMQP）通過點對點和pub-sub方法傳遞消息。它旨在支持復雜的路由邏輯。

有一些托管服務可讓您將其用作SaaS，但它不是本機主要云提供商堆棧的一部分。RabbitMQ支持所有主要語言，包括Python，Java，.NET，PHP，Ruby，JavaScript，Go，Swift等。

在持久模式下，可能會遇到一些性能問題。

kafka

規(guī)模：每秒最多可以發(fā)送一百萬條消息。

持久性：是的。

一對一vs一對多的消費者：只有一對多（乍一看似乎很奇怪，對吧？?。?/p>

Kafka由Linkedin于2011年創(chuàng)建，旨在處理高吞吐量，低延遲的處理。作為一個分布式流平臺，Kafka復制了一個發(fā)布-訂閱服務。它提供數(shù)據(jù)持久性并存儲記錄流，使其能夠交換高質量消息。

Kafka曾在Azure，AWS和Confluent上管理SaaS。他們都是Kafka項目的創(chuàng)建者和主要貢獻者。Kafka支持所有主要語言，包括Python，Java，C / C ++，Clojure，.NET，PHP，Ruby，JavaScript，Go，Swift等。

Redis

規(guī)模：每秒最多可以發(fā)送一百萬條消息。

持久性：基本上不是，它是內存中的數(shù)據(jù)存儲。

一對一與一對多的消費者：兩者都有。

Redis與其他消息代理有點不同。Redis的核心是一個內存中的數(shù)據(jù)存儲，可以用作高性能鍵值存儲或消息代理。另一個區(qū)別是Redis沒有持久性，而是將其內存轉儲到Disk / DB中。它還非常適合實時數(shù)據(jù)處理。

最初，Redis不是一對一和一對多的。但是，由于Redis 5.0引入了pub-sub，因此功能得到了增強，一對多成為真正的選擇。

每個用例的消息代理

我們介紹了RabbitMQ，Kafka和Redis的一些特征。這三種動物都是它們的類別，但是如上所述，它們的運行方式大不相同。這是我們建議正確的消息代理根據(jù)不同用例使用的建議。

短命消息：Redis

Redis的內存數(shù)據(jù)庫幾乎適用于不需要持久性的消息短暫的用例。因為Redis提供了非?？焖俚姆蘸蛢却婀δ?，所以它是短保留消息的理想選擇，在這些消息中持久性不是很重要，您可以容忍一些丟失。隨著5.0中Redis流的發(fā)布，它也成為了一對多用例的候選者，由于局限性和舊的pub-sub功能，絕對需要使用它。

大量數(shù)據(jù)：Kafka

Kafka是一個高吞吐量的分布式隊列，用于長時間存儲大量數(shù)據(jù)。對于需要持久性的一對多用例，Kafka是理想的選擇。

復雜路由：RabbitMQ

RabbitMQ是一個較老但很成熟的代理，具有許多支持復雜路由的功能。當所需速率不高（超過數(shù)萬msg / sec）時，它甚至將支持復雜的路由通信。

考慮您的軟件堆棧

當然，最后要考慮的是您當前的軟件堆棧。如果您正在尋找一個相對簡單的集成過程，并且不想在堆棧中維護其他代理，那么您可能更傾向于使用已由堆棧支持的代理。

例如，如果您在RabbitMQ之上的系統(tǒng)中使用Celery for Task Queue，那么您會獲得與RabbitMQ或Redis一起使用的動力，而不是不支持Kafka且需要進行一些重寫的Kafka。

我們通過平臺的發(fā)展和壯大使用了以上所有內容，然后再進行一些使用！重要的是要記住，每種工具都有自己的優(yōu)點和缺點，這與了解它們并為工作以及特定的時機，情況和要求選擇合適的工具有關。