Redis、Kafka或RabbitMQ中哪个更和微服务更般配
今天就跟大家聊聊有关Redis、Kafka或RabbitMQ中哪个更和微服务更般配，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
将异步通信用于微服务时，通常使用消息代理。代理确保不同微服务之间的通信可靠且稳定，确保消息在系统内得到管理和监视，并且消息不会丢失。您可以选择一些消息代理，它们的规模和数据功能各不相同。这篇博客文章将比较三种最受欢迎的经纪人：RabbitMQ，Kafka和Redis。
但是首先，让我们了解微服务通信。
微服务通信：同步和异步
微服务之间有两种常见的通信方式：同步和异步。在同步通信中，调用方在发送下一条消息之前等待响应，并且它作为HTTP之上的REST协议运行。相反，在异步通信中，无需等待响应即可发送消息。这适用于分布式系统，通常需要消息代理来管理消息。
您选择的通信类型应考虑不同的参数，例如微服务的结构方式，适当的基础架构，延迟，规模，依赖关系以及通信目的。异步通信的建立可能会更加复杂，并且需要添加更多组件才能堆叠，但是将异步通信用于微服务的好处远大于缺点。
异步通讯的优势
首先，根据定义，异步通信是非阻塞的。它也支持比同步操作更好的缩放。第三，在微服务崩溃的情况下，异步通信机制提供了各种恢复技术，通常更擅长处理与崩溃有关的错误。另外，当使用代理而不是REST协议时，接收通信的服务实际上并不需要彼此了解。在旧的服务运行了很长时间之后，甚至可以引入新的服务，即更好的解耦服务。
最后，在选择异步操作时，您将增强将来创建集中发现，监视，负载平衡甚至策略执行器的能力。这将为您提供在代码和系统构建中具有灵活性，可伸缩性和更多功能的功能。
选择合适的消息代理
异步通信通常通过消息代理进行管理。也有其他方法，例如aysncio，但它们更加稀少和有限。
在选择代理执行异步操作时，应考虑以下几点：
代理规模-系统中每秒发送的消息数。 数据持久性-恢复消息的能力。 消费者能力-经纪人是否有能力管理一对一和/或一对多的消费者。
一对一
一对多
我们检查了那里最新和最出色的服务，以找出这三个类别中最强的提供商。
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。
我们通过平台的发展和壮大使用了以上所有内容，然后再进行一些使用！重要的是要记住，每种工具都有自己的优点和缺点，这与了解它们并为工作以及特定的时机，情况和要求选择合适的工具有关。
看完上述内容，你们对Redis、Kafka或RabbitMQ中哪个更和微服务更般配有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。
