微服务消息代理选型:Redis、Kafka、RabbitMQ

开发 前端 Kafka Redis
在为微服务使用异步通信时,通常使用消息代理。代理确保不同微服务之间的通信可靠稳定,消息在系统内得到管理和监控,并且消息不会丢失。

 [[420340]]

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

但首先,让我们了解一下微服务通信。

微服务通信:同步和异步

微服务之间有两种常见的通信方式:同步和异步。在同步通信中,调用方在发送下一条消息之前等待响应,它作为HTTP之上的REST协议运行。相反,在异步通信中,消息是在不等待响应的情况下发送的。这适用于分布式系统,通常需要消息代理来管理消息。

您选择的通信类型应考虑不同的参数,如如何构造微服务、设置什么基础设施、延迟、规模、依赖性和通信目的。异步通信的建立可能更加复杂,并且需要向堆栈中添加更多的组件,但是将异步通信用于微服务的优点大于缺点。

异步通信优势

首先也是最重要的是,异步通信从定义上讲是无阻塞的。它还支持比同步操作更好的扩展。第三,在微服务崩溃的情况下,异步通信机制提供了各种恢复技术,通常更好地处理与崩溃相关的错误。此外,当使用代理而不是REST协议时,接收通信的服务实际上不需要相互了解。甚至可以在旧服务运行很长时间后引入新服务,即更好的解耦服务。

最后,在选择异步操作时,您可以提高将来创建中心发现、监视、负载平衡甚至策略实施器的能力。这将为您的代码和系统构建提供灵活性、可伸缩性和更多功能。

选择正确的消息代理

异步通信通常通过消息代理进行管理。还有其他方法,比如aysncio,但它们更为稀缺和有限。

在选择执行异步操作的代理时,应考虑以下几点:

1. Broker Scale–系统中每秒发送的消息数。

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

3. 消费者能力–brokers是否能够管理一对一和/或一对多消费者。

一对一:

一对多:

我们查看了最新和最好的服务,以找出这三个类别中哪家提供商最强。

比较不同的消息代理

RabbitMQ(AMQP)

规模:根据配置和资源,这里的大概速度约为每秒50K味精。

持久化:支持持久性和暂时性消息。

一对一vs一对多消费者:两者皆有。

RabbitMQ于2007年发布,是首批创建的通用消息代理之一。它是一个开源软件,通过实现高级消息队列协议(AMQP),通过点对点和发布子方法来传递消息。它旨在支持复杂的路由逻辑。

有一些托管服务允许您将其用作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

规模:每秒最多可发送一百万条消息。

持久化:基本上不是——它是内存中的数据存储。

一对一vs一对多消费者:两者皆有。

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

最初,Redis不是一对一和一对多。然而,自从Redis 5.0推出pub-sub以来,功能得到了提升,一对多成为了一种现实选择。

每个用例的消息代理

我们介绍了RabbitMQ、卡夫卡和Redis的一些特性。这三种动物都属于这一类,但如上所述,它们的运作方式截然不同。下面是我们根据不同的用例为正确的MessageBroker提供的建议。

短消息:Redis

Redis的内存数据库几乎完全适合于不需要持久性的短消息用例。因为它提供了极快的服务和内存功能,Redis是短保留消息的完美选择,在短保留消息中,持久性并不重要,您可以容忍一些损失。随着Redis streams在5.0中的发布,它也是一对多用例的候选者,这是由于限制和旧的发布订阅功能而绝对需要的。

大量数据:Kafka

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

复杂路由:RabbitMQ

RabbitMQ是一个较老但成熟的代理,具有许多支持复杂路由的特性和功能。当所需速率不高(超过数万msg/秒)时,它甚至支持复杂的路由通信。

考虑你的软件栈

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

例如,如果您在RabbitMQ之上的系统中使用芹菜作为任务队列,您将有动力使用RabbitMQ或Redis,而不是Kafka,后者不受支持,需要一些重写。

 

责任编辑:张燕妮 来源: 老K的Java博客
相关推荐

2022-02-13 23:04:28

RedisRabbitMQKafka

2019-09-23 10:47:52

Kafka架构微服务

2023-09-06 14:11:03

数据库Redis消息队列

2019-05-29 14:49:02

KafkaRocketMQRabbitMQ

2019-04-11 10:26:15

架构运维技术

2020-04-02 10:37:55

微服务架构数据

2021-01-04 09:35:55

微服务架构配置中心

2020-11-25 09:56:48

架构运维技术

2011-08-17 11:26:10

2023-08-27 16:13:50

架构微服务器

2022-05-31 08:21:07

MQ使用场景消费消息

2021-02-24 14:01:13

微服务开发框架

2022-03-23 09:00:00

微服务KafkaChronicle

2017-12-20 15:37:39

Spring Clou微服务架构

2023-03-27 15:39:53

微服务架构REST

2019-01-04 09:59:14

KafkaRabbitMQMQ

2023-09-18 08:27:20

RabbitMQRocketMQKafka

2020-09-11 09:44:04

微服务分布式链路

2023-06-20 08:59:25

微服务注册中心运维

2022-07-01 08:36:44

流编排主流框架
点赞
收藏

51CTO技术栈公众号