微服務(wù)消息代理選型：Redis、Kafka、RabbitMQ

作者：佚名 2021-08-30 11:36:23

開發(fā)

前端

Kafka

Redis 在為微服務(wù)使用異步通信時(shí)，通常使用消息代理。代理確保不同微服務(wù)之間的通信可靠穩(wěn)定，消息在系統(tǒng)內(nèi)得到管理和監(jiān)控，并且消息不會(huì)丟失。

 [[420340]]

在為微服務(wù)使用異步通信時(shí)，通常使用消息代理。代理確保不同微服務(wù)之間的通信可靠穩(wěn)定，消息在系統(tǒng)內(nèi)得到管理和監(jiān)控，并且消息不會(huì)丟失。您可以從幾個(gè)消息代理中選擇，它們的規(guī)模和數(shù)據(jù)功能各不相同。這篇博文將比較三個(gè)最受歡迎的代理brokers：RabbitMQ、 Kafka 和 Redis 。

但首先，讓我們了解一下微服務(wù)通信。

微服務(wù)通信：同步和異步

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

您選擇的通信類型應(yīng)考慮不同的參數(shù)，如如何構(gòu)造微服務(wù)、設(shè)置什么基礎(chǔ)設(shè)施、延遲、規(guī)模、依賴性和通信目的。異步通信的建立可能更加復(fù)雜，并且需要向堆棧中添加更多的組件，但是將異步通信用于微服務(wù)的優(yōu)點(diǎn)大于缺點(diǎn)。

異步通信優(yōu)勢(shì)

首先也是最重要的是，異步通信從定義上講是無阻塞的。它還支持比同步操作更好的擴(kuò)展。第三，在微服務(wù)崩潰的情況下，異步通信機(jī)制提供了各種恢復(fù)技術(shù)，通常更好地處理與崩潰相關(guān)的錯(cuò)誤。此外，當(dāng)使用代理而不是REST協(xié)議時(shí)，接收通信的服務(wù)實(shí)際上不需要相互了解。甚至可以在舊服務(wù)運(yùn)行很長時(shí)間后引入新服務(wù)，即更好的解耦服務(wù)。

最后，在選擇異步操作時(shí)，您可以提高將來創(chuàng)建中心發(fā)現(xiàn)、監(jiān)視、負(fù)載平衡甚至策略實(shí)施器的能力。這將為您的代碼和系統(tǒng)構(gòu)建提供靈活性、可伸縮性和更多功能。

選擇正確的消息代理

異步通信通常通過消息代理進(jìn)行管理。還有其他方法，比如aysncio，但它們更為稀缺和有限。

在選擇執(zhí)行異步操作的代理時(shí)，應(yīng)考慮以下幾點(diǎn)：

1. Broker Scale–系統(tǒng)中每秒發(fā)送的消息數(shù)。

2. 數(shù)據(jù)持久性–恢復(fù)消息的能力。

3. 消費(fèi)者能力–brokers是否能夠管理一對(duì)一和/或一對(duì)多消費(fèi)者。

一對(duì)一：

一對(duì)多：

我們查看了最新和最好的服務(wù)，以找出這三個(gè)類別中哪家提供商最強(qiáng)。

比較不同的消息代理

RabbitMQ（AMQP）

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

持久化：支持持久性和暫時(shí)性消息。

一對(duì)一vs一對(duì)多消費(fèi)者：兩者皆有。

RabbitMQ于2007年發(fā)布，是首批創(chuàng)建的通用消息代理之一。它是一個(gè)開源軟件，通過實(shí)現(xiàn)高級(jí)消息隊(duì)列協(xié)議（AMQP），通過點(diǎn)對(duì)點(diǎn)和發(fā)布子方法來傳遞消息。它旨在支持復(fù)雜的路由邏輯。

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

在持久模式下可能會(huì)出現(xiàn)一些性能問題。

Kafka

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

持久化：是的。

一對(duì)一vs一對(duì)多消費(fèi)者：只有一對(duì)多（乍一看似乎很奇怪，對(duì)吧？?。?/p>

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

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

Redis

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

持久化：基本上不是——它是內(nèi)存中的數(shù)據(jù)存儲(chǔ)。

一對(duì)一vs一對(duì)多消費(fèi)者：兩者皆有。

Redis與其他消息代理稍有不同。Redis的核心是內(nèi)存中的數(shù)據(jù)存儲(chǔ)，可以用作高性能鍵值存儲(chǔ)或消息代理。另一個(gè)區(qū)別是Redis沒有持久性，而是將其內(nèi)存轉(zhuǎn)儲(chǔ)到磁盤/DB中。它也非常適合實(shí)時(shí)數(shù)據(jù)處理。

最初，Redis不是一對(duì)一和一對(duì)多。然而，自從Redis 5.0推出pub-sub以來，功能得到了提升，一對(duì)多成為了一種現(xiàn)實(shí)選擇。

每個(gè)用例的消息代理

我們介紹了RabbitMQ、卡夫卡和Redis的一些特性。這三種動(dòng)物都屬于這一類，但如上所述，它們的運(yùn)作方式截然不同。下面是我們根據(jù)不同的用例為正確的MessageBroker提供的建議。

短消息：Redis

Redis的內(nèi)存數(shù)據(jù)庫幾乎完全適合于不需要持久性的短消息用例。因?yàn)樗峁┝藰O快的服務(wù)和內(nèi)存功能，Redis是短保留消息的完美選擇，在短保留消息中，持久性并不重要，您可以容忍一些損失。隨著Redis streams在5.0中的發(fā)布，它也是一對(duì)多用例的候選者，這是由于限制和舊的發(fā)布訂閱功能而絕對(duì)需要的。

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

Kafka是一個(gè)高吞吐量的分布式隊(duì)列，用于長時(shí)間存儲(chǔ)大量數(shù)據(jù)。Kafka非常適合于需要持久性的一對(duì)多用例。

復(fù)雜路由：RabbitMQ

RabbitMQ是一個(gè)較老但成熟的代理，具有許多支持復(fù)雜路由的特性和功能。當(dāng)所需速率不高（超過數(shù)萬msg/秒）時(shí)，它甚至支持復(fù)雜的路由通信。

考慮你的軟件棧

當(dāng)然，最后要考慮的是您當(dāng)前的軟件堆棧。如果您正在尋找一個(gè)相對(duì)簡單的集成過程，并且不希望在堆棧中維護(hù)不同的代理，那么您可能更傾向于使用堆棧已經(jīng)支持的代理。

例如，如果您在RabbitMQ之上的系統(tǒng)中使用芹菜作為任務(wù)隊(duì)列，您將有動(dòng)力使用RabbitMQ或Redis，而不是Kafka，后者不受支持，需要一些重寫。

 

分享標(biāo)題：微服務(wù)消息代理選型：Redis、Kafka、RabbitMQ
路徑分享：http://www.dlmjj.cn/article/dpchepc.html