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