Redis、Kafka或RabbitMQ：選擇哪個作為微服務訊息代理？ - otonomo

微服務通訊：同步和非同步
微服務之間有兩種常見的通訊方式：同步和非同步。在同步通訊中，呼叫方在傳送下一條訊息之前等待響應，並且它作為HTTP之上的REST協議執行。相反，在非同步通訊中，無需等待響應即可傳送訊息。這適用於分散式系統，通常需要訊息代理來管理訊息。
您選擇的通訊型別應考慮不同的引數，例如微服務的結構方式，適當的基礎架構，延遲，規模，依賴關係以及通訊目的。非同步通訊的建立可能會更加複雜，並且需要新增更多元件才能堆疊，但是將非同步通訊用於微服務的好處遠大於缺點。
 

非同步通訊的優勢
首先，根據定義，非同步通訊是非阻塞的。它也支援比同步操作更好的縮放。第三，在微服務崩潰的情況下，非同步通訊機制提供了各種恢復技術，通常更擅長處理與崩潰有關的錯誤。另外，當使用代理而不是REST協議時，接收通訊的服務實際上並不需要彼此瞭解。在舊的服務執行了很長時間之後，甚至可以引入新的服務，即更好的解耦服務。
最後，在選擇非同步操作時，您將增強將來建立集中發現，監視，負載平衡甚至策略執行器的能力。這將為您提供在程式碼和系統構建中具有靈活性，可伸縮性和更多功能的功能。
 

選擇合適的訊息代理
非同步通訊通常透過訊息代理進行管理。也有其他方法，例如aysncio，但它們更加稀少和有限。
在選擇代理執行非同步操作時，應考慮以下幾點：

1. 代理規模–系統中每秒傳送的訊息數。
2. 資料永續性–恢復訊息的能力。
3. 消費者能力–經紀人是否有能力管理一對一和/或一對多的消費者。

一對一

一對多

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

RabbitMQ（AMQP）

規模：根據配置和資源，這裡的執行速度約為每秒50K msg。

永續性：支援永續性訊息和瞬時訊息。

一對一與一對多的消費者：兩者都有。
RabbitMQ於2007年釋出，是最早建立的常見訊息代理之一。它是一個開放原始碼，透過實現高階訊息佇列協議（AMQP）透過點對點和pub-sub方法傳遞訊息。它旨在支援複雜的路由邏輯。
有一些託管服務可讓您將其用作SaaS，但它不是本機主要雲提供商堆疊的一部分。RabbitMQ支援所有主要語言，包括Python，Java，.NET，PHP，Ruby，JavaScript，Go，Swift等。
在持久模式下，可能會遇到一些效能問題。

kafka

規模：每秒最多可以傳送一百萬條訊息。

永續性：是的。

一對一vs一對多的消費者：只有一對多（乍一看似乎很奇怪，對吧？！）。
Kafka由Linkedin於2011年建立，旨在處理高吞吐量，低延遲的處理。作為一個分散式流平臺，Kafka複製了一個釋出-訂閱服務。它提供資料永續性並儲存記錄流，使其能夠交換高質量訊息。
Kafka曾在Azure，AWS和Confluent上管理SaaS。他們都是Kafka專案的建立者和主要貢獻者。Kafka支援所有主要語言，包括Python，Java，C / C ++，Clojure，.NET，PHP，Ruby，JavaScript，Go，Swift等。
 

Redis

規模：每秒最多可以傳送一百萬條訊息。

永續性：基本上不是，它是記憶體中的資料儲存。

一對一與一對多的消費者：兩者都有。
Redis與其他訊息代理有點不同。Redis的核心是一個記憶體中的資料儲存，可以用作高效能鍵值儲存或訊息代理。另一個區別是Redis沒有永續性，而是將其記憶體轉儲到Disk / DB中。它還非常適合實時資料處理。
最初，Redis不是一對一和一對多的。但是，由於Redis 5.0引入了pub-sub，因此功能得到了增強，一對多成為真正的選擇。
 

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

短命訊息：Redis

Redis的記憶體資料庫幾乎適用於不需要永續性的訊息短暫的用例。因為Redis提供了非常快速的服務和記憶體功能，所以它是短保留訊息的理想選擇，在這些訊息中永續性不是很重要，您可以容忍一些丟失。隨著5.0中Redis流的釋出，它也成為了一對多用例的候選者，由於侷限性和舊的pub-sub功能，絕對需要使用它。
 

大量資料：Kafka

Kafka是一個高吞吐量的分散式佇列，用於長時間儲存大量資料。對於需要永續性的一對多用例，Kafka是理想的選擇。
 

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

考慮您的軟體堆疊
當然，最後要考慮的是您當前的軟體堆疊。如果您正在尋找一個相對簡單的整合過程，並且不想在堆疊中維護其他代理，那麼您可能更傾向於使用已由堆疊支援的代理。
例如，如果您在RabbitMQ之上的系統中使用Celery for Task Queue，那麼您會獲得與RabbitMQ或Redis一起使用的動力，而不是不支援Kafka且需要進行一些重寫的​​Kafka。
在Otonomo，我們透過平臺的發展和壯大使用了以上所有內容，然後再進行一些使用！重要的是要記住，每種工具都有自己的優點和缺點，這與瞭解它們併為工作以及特定的時機，情況和要求選擇合適的工具有關。