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

作者&＃xff1a;otonomo

来源&＃xff1a;https://www.jdon.com/55161

将异步通信用于微服务时&＃xff0c;通常使用消息代理。代理确保不同微服务之间的通信可靠且稳定&＃xff0c;确保消息在系统内得到管理和监视&＃xff0c;并且消息不会丢失。您可以选择一些消息代理&＃xff0c;它们的规模和数据功能各不相同。这篇博客文章将比较三种最受欢迎的经纪人&＃xff1a;RabbitMQ&＃xff0c;Kafka和Redis。

但是首先&＃xff0c;让我们了解微服务通信。

微服务通信&＃xff1a;同步和异步

微服务之间有两种常见的通信方式&＃xff1a;同步和异步。在同步通信中&＃xff0c;调用方在发送下一条消息之前等待响应&＃xff0c;并且它作为HTTP之上的REST协议运行。相反&＃xff0c;在异步通信中&＃xff0c;无需等待响应即可发送消息。这适用于分布式系统&＃xff0c;通常需要消息代理来管理消息。

您选择的通信类型应考虑不同的参数&＃xff0c;例如微服务的结构方式&＃xff0c;适当的基础架构&＃xff0c;延迟&＃xff0c;规模&＃xff0c;依赖关系以及通信目的。异步通信的建立可能会更加复杂&＃xff0c;并且需要添加更多组件才能堆叠&＃xff0c;但是将异步通信用于微服务的好处远大于缺点。

异步通讯的优势

首先&＃xff0c;根据定义&＃xff0c;异步通信是非阻塞的。它也支持比同步操作更好的缩放。第三&＃xff0c;在微服务崩溃的情况下&＃xff0c;异步通信机制提供了各种恢复技术&＃xff0c;通常更擅长处理与崩溃有关的错误。另外&＃xff0c;当使用代理而不是REST协议时&＃xff0c;接收通信的服务实际上并不需要彼此了解。在旧的服务运行了很长时间之后&＃xff0c;甚至可以引入新的服务&＃xff0c;即更好的解耦服务。

最后&＃xff0c;在选择异步操作时&＃xff0c;您将增强将来创建集中发现&＃xff0c;监视&＃xff0c;负载平衡甚至策略执行器的能力。这将为您提供在代码和系统构建中具有灵活性&＃xff0c;可伸缩性和更多功能的功能。

选择合适的消息代理

异步通信通常通过消息代理进行管理。也有其他方法&＃xff0c;例如aysncio&＃xff0c;但它们更加稀少和有限。

在选择代理执行异步操作时&＃xff0c;应考虑以下几点&＃xff1a;

1. 代理规模–系统中每秒发送的消息数。

2. 数据持久性–恢复消息的能力。

3. 消费者能力–经纪人是否有能力管理一对一和/或一对多的消费者。

一对一

一对多

我们检查了那里最新和最出色的服务&＃xff0c;以找出这三个类别中最强的提供商。

RabbitMQ&＃xff08;AMQP&＃xff09;

规模&＃xff1a;根据配置和资源&＃xff0c;这里的运行速度约为每秒50K msg。

持久性&＃xff1a;支持持久性消息和瞬时消息。

一对一与一对多的消费者&＃xff1a;两者都有。

RabbitMQ于2007年发布&＃xff0c;是最早创建的常见消息代理之一。它是一个开放源代码&＃xff0c;通过实现高级消息队列协议&＃xff08;AMQP&＃xff09;通过点对点和pub-sub方法传递消息。它旨在支持复杂的路由逻辑。

有一些托管服务可让您将其用作SaaS&＃xff0c;但它不是本机主要云提供商堆栈的一部分。RabbitMQ支持所有主要语言&＃xff0c;包括Python&＃xff0c;Java&＃xff0c;.NET&＃xff0c;PHP&＃xff0c;Ruby&＃xff0c;Javascript&＃xff0c;Go&＃xff0c;Swift等。

在持久模式下&＃xff0c;可能会遇到一些性能问题。

kafka

规模&＃xff1a;每秒最多可以发送一百万条消息。

持久性&＃xff1a;是的。

一对一vs一对多的消费者&＃xff1a;只有一对多&＃xff08;乍一看似乎很奇怪&＃xff0c;对吧&＃xff1f;&＃xff01;&＃xff09;。

Kafka由Linkedin于2011年创建&＃xff0c;旨在处理高吞吐量&＃xff0c;低延迟的处理。作为一个分布式流平台&＃xff0c;Kafka复制了一个发布-订阅服务。它提供数据持久性并存储记录流&＃xff0c;使其能够交换高质量消息。

Kafka曾在Azure&＃xff0c;AWS和Confluent上管理SaaS。他们都是Kafka项目的创建者和主要贡献者。Kafka支持所有主要语言&＃xff0c;包括Python&＃xff0c;Java&＃xff0c;C / C &＃43;&＃43;&＃xff0c;Clojure&＃xff0c;.NET&＃xff0c;PHP&＃xff0c;Ruby&＃xff0c;Javascript&＃xff0c;Go&＃xff0c;Swift等。

Redis

规模&＃xff1a;每秒最多可以发送一百万条消息。

持久性&＃xff1a;基本上不是&＃xff0c;它是内存中的数据存储。

一对一与一对多的消费者&＃xff1a;两者都有。

Redis与其他消息代理有点不同。Redis的核心是一个内存中的数据存储&＃xff0c;可以用作高性能键值存储或消息代理。另一个区别是Redis没有持久性&＃xff0c;而是将其内存转储到Disk / DB中。它还非常适合实时数据处理。

最初&＃xff0c;Redis不是一对一和一对多的。但是&＃xff0c;由于Redis 5.0引入了pub-sub&＃xff0c;因此功能得到了增强&＃xff0c;一对多成为真正的选择。

每个用例的消息代理

我们介绍了RabbitMQ&＃xff0c;Kafka和Redis的一些特征。这三种动物都是它们的类别&＃xff0c;但是如上所述&＃xff0c;它们的运行方式大不相同。这是我们建议正确的消息代理根据不同用例使用的建议。

短命消息&＃xff1a;Redis

Redis的内存数据库几乎适用于不需要持久性的消息短暂的用例。因为Redis提供了非常快速的服务和内存功能&＃xff0c;所以它是短保留消息的理想选择&＃xff0c;在这些消息中持久性不是很重要&＃xff0c;您可以容忍一些丢失。随着5.0中Redis流的发布&＃xff0c;它也成为了一对多用例的候选者&＃xff0c;由于局限性和旧的pub-sub功能&＃xff0c;绝对需要使用它。

大量数据&＃xff1a;Kafka

Kafka是一个高吞吐量的分布式队列&＃xff0c;用于长时间存储大量数据。对于需要持久性的一对多用例&＃xff0c;Kafka是理想的选择。

复杂路由&＃xff1a;RabbitMQ

RabbitMQ是一个较老但很成熟的代理&＃xff0c;具有许多支持复杂路由的功能。当所需速率不高&＃xff08;超过数万msg / sec&＃xff09;时&＃xff0c;它甚至将支持复杂的路由通信。

考虑您的软件堆栈

当然&＃xff0c;最后要考虑的是您当前的软件堆栈。如果您正在寻找一个相对简单的集成过程&＃xff0c;并且不想在堆栈中维护其他代理&＃xff0c;那么您可能更倾向于使用已由堆栈支持的代理。

例如&＃xff0c;如果您在RabbitMQ之上的系统中使用Celery for Task Queue&＃xff0c;那么您会获得与RabbitMQ或Redis一起使用的动力&＃xff0c;而不是不支持Kafka且需要进行一些重写的Kafka。

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

Redis 分布式锁使用不当&＃xff0c;超卖了100瓶飞天茅台&＃xff01;&＃xff01;&＃xff01;
SQL优化最干货总结&＃xff08;2021最新版&＃xff09;Redis 分布式锁使用不当&＃xff0c;超卖了100瓶飞天茅台&＃xff01;&＃xff01;&＃xff01;为什么MySQL不推荐使用 UUID 或者雪花id作为主键&＃xff1f;
今天&＃xff0c;又被Java8的时间库恶心到了&＃xff0c;有同感的举手...
Docker从入门到干活&＃xff0c;看这一篇足矣
程序员需知的 58 个网站好文章&＃xff0c;我在看