Redis、Kafka或RabbitMQ中哪个更和微服务更般配

但是首先，让我们了解微服务通信。

微服务通信：同步和异步

微服务之间有两种常见的通信方式：同步和异步。在同步通信中，调用方在发送下一条消息之前等待响应，并且它作为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。

我们通过平台的发展和壮大使用了以上所有内容，然后再进行一些使用！重要的是要记住，每种工具都有自己的优点和缺点，这与了解它们并为工作以及特定的时机，情况和要求选择合适的工具有关。