对微服务使用异步通信时，通常使用消息代理。代理确保不同微服务之间的通信可靠且稳定，消息在系统内得到管理和监控，并且消息不会丢失。您可以从几个消息代理中进行选择，它们的规模和数据功能各不相同。这篇博文将比较三种最受欢迎的代理：RabbitMQ、Kafka 和 Redis。

微服务通信：同步和异步

微服务之间有两种常见的通信方式：同步和异步。在同步通信中，调用者在发送下一条消息之前等待响应，它作为 HTTP 之上的 REST 协议运行。相反，在异步通信中，消息是在不等待响应的情况下发送的。这适用于分布式系统，通常需要消息代理来管理消息。
您选择的通信类型应考虑不同的参数，例如您如何构建微服务、您拥有的基础设施、延迟、规模、依赖关系和通信目的。异步通信的建立可能更复杂，需要向堆栈中添加更多组件，但对微服务使用异步通信的优点大于缺点。

异步通信优势

首先，异步通信根据定义是非阻塞的。它还支持比同步操作更好的扩展。第三，在微服务崩溃的情况下，异步通信机制提供了各种恢复技术，并且通常更擅长处理与崩溃有关的错误。此外，当使用代理而不是 REST 协议时，接收通信的服务实际上不需要相互了解。甚至可以在旧服务运行很长时间后引入新服务，即更好的解耦服务。
最后，在选择异步操作时，您可以提高未来创建中央发现、监控、负载平衡甚至策略执行器的能力。这将为您的代码和系统构建提供灵活性、可扩展性和更多功能。

选择正确的消息代理

异步通信通常通过消息代理进行管理。还有其他方法，例如 aysncio，但它们更加稀缺和有限。
在选择代理来执行异步操作时，您应该考虑以下几点：
Broker Scale — 系统中每秒发送的消息数。
数据持久性——恢复消息的能力。
消费者能力——经纪人是否能够管理一对一和/或一对多的消费者。

一对一

一对多

我们检查了最新和最好的服务，以找出这三个类别中最强大的提供商。

比较不同的消息代理

RabbitMQ (AMQP)

规模：

根据配置和资源，这里的大概是每秒 50K msg。
持久性：

支持持久性和瞬态消息。
一对一与一对多消费者：

两者兼而有之。
RabbitMQ 于 2007 年发布，是最早创建的通用消息代理之一。它是一个开源软件，通过实现高级消息队列协议 (AMQP)，通过点对点和发布-订阅方法传递消息。它旨在支持复杂的路由逻辑。
有一些托管服务允许您将其用作 SaaS，但它不是本地主要云提供商堆栈的一部分。RabbitMQ 支持所有主要语言，包括 Python、Java、.NET、PHP、Ruby、JavaScript、Go、Swift 等。
在持久模式下会出现一些性能问题。

卡夫卡

规模：

每秒最多可以发送一百万条消息。
持久化：

是的。
一对一 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 没有持久性，而是将其内存转储到磁盘/数据库中。它也非常适合实时数据处理。
最初，Redis 不是一对一和一对多的。然而，自从 Redis 5.0 引入了 pub-sub，功能得到了提升，一对多成为了一个真正的选择。

每个消息代理的用例

我们介绍了 RabbitMQ、Kafka 和 Redis 的一些特性。这三者都是同类中的野兽，但正如所描述的，它们的运作方式大不相同。以下是我们针对不同用例使用的正确消息代理的建议。

短命消息：Redis

Redis 的内存数据库几乎非常适合具有不需要持久性的短期消息的用例。因为它提供极快的服务和内存中的功能，Redis 是短保留消息的完美候选者，在这种情况下，持久性不是那么重要，您可以容忍一些损失。随着 5.0 中 Redis 流的发布，它也是一对多用例的候选者，由于限制和旧的 pub-sub 功能，这是绝对需要的。

海量数据：Kafka

Kafka 是一个高吞吐量的分布式队列，专为长时间存储大量数据而构建。Kafka 非常适合需要持久性的一对多用例。

复杂路由：RabbitMQ

RabbitMQ 是一个较旧但成熟的代理，具有许多支持复杂路由的特性和功能。当要求的速率不高（超过几万条消息/秒）时，它甚至会支持复杂的路由通信。

考虑您的软件堆栈

当然，最后要考虑的是您当前的软件堆栈。如果您正在寻找一个相对简单的集成过程，并且您不想在一个堆栈中维护不同的代理，您可能更倾向于使用您的堆栈已经支持的代理。
例如，如果您在 RabbitMQ 之上的系统中使用 Celery for Task Queue，您将有动力使用 RabbitMQ 或 Redis，而不是 Kafka，后者不受支持并且需要一些重写。

本文 :https://architect.pub/redis-vs-kafka-vs-rabbitmq
讨论：知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】
公众号	【jiagoushipro】【超级架构师】精彩图文详解架构方法论，架构实践，技术原理，技术趋势。我们在等你，赶快扫描关注吧。
微信小号	【ca_cea】 50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化.
QQ群	【285069459】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。加QQ群，有珍贵的报告和干货资料分享。
视频号	【超级架构师】 1分钟快速了解架构相关的基本概念，模型，方法，经验。每天1分钟，架构心中熟。
知识星球	【首席架构师圈】向大咖提问，近距离接触，或者获得私密资料分享。
喜马拉雅	【超级架构师】路上或者车上了解最新黑科技资讯，架构心得。	【智能时刻，架构君和你聊黑科技】
知识星球	认识更多朋友，职场和技术闲聊。	知识星球【职场和技术】
领英	Harry	https://www.linkedin.com/in/architect-harry/
领英群组	领英架构群组	https://www.linkedin.com/groups/14209750/
微博‍‍	【超级架构师】	智能时刻‍
哔哩哔哩	【超级架构师】
抖音	【cea_cio】超级架构师
快手	【cea_cio_cto】超级架构师
小红书	【cea_csa_cto】超级架构师
网站	CIO(首席信息官)	https://cio.ceo
网站	CIO,CTO和CDO	https://cioctocdo.com
网站	架构师实战分享	https://architect.pub
网站	程序员云开发分享	https://pgmr.cloud
网站	首席架构师社区	https://jiagoushi.pro
网站	应用开发和开发平台	https://apaas.dev
网站	开发信息网	https://xinxi.dev
网站	超级架构师	https://jiagou.dev
网站	企业技术培训	https://peixun.dev
网站	程序员宝典	https://pgmr.pub
网站	开发者闲谈	https://blog.developer.chat
网站	CPO宝典	https://cpo.work
网站	首席安全官	https://cso.pub ‍
网站	CIO酷	https://cio.cool
网站	CDO信息	https://cdo.fyi
网站	CXO信息	https://cxo.pub