Redis、Kafka与RabbitMQ不完全对比
当我们在微服务中使用异步通信时，通常都会用到消息代理。
消息代理（Message Agent）可以确保不同微服务之间的通信可靠稳定，消息在系统内也能得到管理和监控，消息也不会丢失。
当今商用和开源的消息代理有很多个，它们的规模和数据能力各不相同。本文将带来三个最流行的开源消息代理的比较。
这三个消息代理分别是：RabbitMQ、Kafka 与 Redis。
微服务通信：同步还是异步？
微服务之间有两种常见的通信方式：同步和异步方式。
在同步通信协议中，调用者在发送下一条消息之前要等待客户端响应，它作为 HTTP 之上的 REST 协议运行。
而在异步通信中，消息是不必等待响应的情况下就发送的。这种机制适用于分布式系统，通常需要消息代理来管理消息。
首要选择的通信类型应该考虑不同的参数，例如你是如何构建微服务的、你有什么基础设施、延迟、规模、依赖关系和通信的目的。
异步通信可能让技术更复杂，并且需要向技术栈中添加更多组件，但对于微服务，使用异步通信的优点大于缺点，这一点是确定的。
异步通信的优势
首先，异步通信根据定义是非阻塞的机制；
第二，它还支持比同步通信有更好的伸缩性；
第三，在微服务崩溃的情况下，异步通信机制提供了各种恢复技术，并且在一通常情况下能更好地处理与系统崩溃有关的错误。
此外，当使用消息代理而不是 REST 协议时，接收通信的服务实际上并不需要相互了解，甚至可以在旧服务运行很长时间后引入新服务，能够有更好的解耦服务。
最后，在选择异步消息时，开发者可以提高在未来创建中心发现、监控、负载均衡甚至策略执行器的能力，从而为代码和系统构建提供灵活性、可扩展性以及更多功能。
选择最适合的消息代理
异步通信通常通过消息代理进行管理。当然，还有其他方法，例如aysncio，但它们更加稀缺和有限。
在选择执行异步操作的消息代理时，开发者应该考虑以下几点：
Broker Scale — 系统中每秒发送的消息数。
数据持久性——恢复消息的能力。
消费者能力——代理是否能够管理一对一和/或一对多的消费者。
一对一
一对多
以下通过数据与案例说明，那个消息代理是最新和最好的，以便帮助开发者找出这三个产品中哪个功能最强大，哪个最适合自己。
不同消息代理的比较
RabbitMQ (AMQP)
规模：基于配置和资源，例如大约是每秒收发 50K 消息；
持久性：支持持久性和瞬态消息；
一对一与一对多消费者：两者兼而有之。
RabbitMQ 于 2007 年发布，是最早出现的通用消息代理之一。
它是一个开源软件，通过实现高级消息队列协议 (AMQP) 通过点对点和发布订阅方法传递消息。它的能力在于能够支持复杂的路由逻辑。
有一些云服务商或网络托管服务商也将其做成了 SaaS 服务。RabbitMQ 支持所有主流语言，包括 Python、Java、.NET、PHP、Ruby、JavaScript、Go、Swift 等。
RabbitMQ 在持久模式下会存在一些性能问题。
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 没有持久存储，而是将其内存转储到磁盘/数据库中，它非常适合实时数据处理。
最初Redis 并不支持一对一和一对多的机能。从 Redis 5.0 开始引入了 pub-sub 特性，其功能得到了提升，一对多成为了一个真正的选择。
几个消息代理的应用场景
上面我们介绍了 RabbitMQ、Kafka 和 Redis 的一些特性。这三者都是同类系统中的佼佼者。我们从前面所述内容中看到，它们的运作方式有着截然不同，这需要人们根据不同用例，选择使用正确的消息代理。
短消息：Redis
Redis 的内存数据库几乎完美适用于不需要持久性存储的短消息用例。
Redis提供了极快的服务和内存存储功能，是短保留消息的完美候选者，在某种情况下持久性并不那么重要，并且可以容忍一些数据损失。
随着 Redis Stream 在 5.0 中的发布，它也是一对多用例的候选者，特别是新的 pub-sub 功能，这也是开发者和用户所需要的。
海量数据：Kafka
Kafka 是一个高吞吐量分布式队列，专为长时间存储大量数据而构建。Kafka 非常适合需要持久性的一对多用例。
复杂路由：RabbitMQ
RabbitMQ 是一个较老但成熟的消息代理，它具有许多支持复杂路由的特性和功能。甚至在所需速率不高（几万个消息/秒以上）的情况下，它甚至可以支持比较复杂的路由通信。
思考你自己的技术栈
最后的考虑因素是我们当前所使用的软件技术栈。
如果你正在寻找一个相对集成过程相对简单，并且不想在技术栈中维护不同的代理，你可能更倾向于这个技术栈中已经支持的消息代理。
例如，如果在系统中 RabbitMQ 之上使用 Celery 用于任务队列，那么我们将有动力使用 RabbitMQ 或 Redis，而不必再使用不受支持且需要再写一些代码的 Kafka。
每种工具都有自己的优点和缺点，希望本文能够帮助你理解这些各具特点的消息代理，为工作以及特定的任务选择最为正确的开发工具。
编译：洛逸
来源：https://mertcanarguc.medium.com/redis-vs-kafka-vs-rabbitmq-e935ebbc7ec
相关阅读：