Redis、Kafka或RabbitMQ：哪个作为微服务消息代理最合适？

Posted 2023-05-05

参考技术A

将异步通信用于微服务的场合，通常使用消息代理(Message Broker)。消息代理确保不同微服务之间的通信可靠稳定，保证消息在系统内得到管理和监视，并且消息不会被丢失。

开发者可以选择的一些消息代理有很多，它们的规模和数据功能各不相同。本篇文章将比较三种最受欢迎的消息代理：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曾在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。

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

rabbitmq和kafka的区别

RabbitMQ,遵循AMQP协议，由内在高并发的erlang语言开发，用在实时的对可靠性要求比较高的消息传递上。
kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。

1)在架构模型方面，

RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制。

kafka遵从一般的MQ结构，producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。

2)在吞吐量，

kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。

rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。

3)在可用性方面，

rabbitMQ支持miror的queue，主queue失效，miror queue接管。

kafka的broker支持主备模式。

4)在集群负载均衡方面，

kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。

rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

所以关于这两个选择，我们还是了解了这4个大致的区别。关于高吞吐，以及我们队日志的特定场景分析，任然选择了，kafka。当然设计理念不一样，rabbitMQ用于可靠的消息传递，智齿事物，不支持批量的操作，可用性差不多，只是实现不一样。在集群方面，kafka胜一筹，通过topic注册zookeeper，调用机制，实现语义指定分片，然而rabbitMQ的负载需要单独loadbalancer支持

————————————————
版权声明：本文为CSDN博主「大壮vip」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_33792843/article/details/75727911 参考技术A Kafka在吞吐量处理上要比RabbitMQ强很多
rabbitMQ支持miror的queue，主queue失效，miror queue接管。 参考技术B 回答

这篇文章会先介绍一下基本的异步消息模式，然后再介绍一下RabbitMQ和Kafka以及他们的内部结构信息。第二部分（未完成）主要介绍这两种技术的主要不同点以及他们各自的优缺点，最后我们会说明一下怎样选择这两种技术。

异步消息模式

异步消息可以作为解耦消息的生产和处理的一种解决方案。提到消息系统，我们通常会想到两种主要的消息模式——消息队列和发布/订阅模式。

消息队列

利用消息队列可以解耦生产者和消费者。多个生产者可以向同一个消息队列发送消息；但是，一个消息在被一个消息者处理的时候，这个消息在队列上会被锁住或者被移除并且其他消费者无法处理该消息。也就是说一个具体的消息只能由一个消费者消费。

消息队列

需要额外注意的是，如果消费者处理一个消息失败了，消息系统一般会把这个消息放回队列，这样其他消费者可以继续处理。消息队列除了提供解耦功能之外，它还能够对生产者和消费者进行独立的伸缩（scale），以及提供对错误处理的容错能力。

发布/订阅

发布/订阅（pub/sub）模式中，单个消息可以被多个订阅者并发的获取和处理。

发布/订阅

例如，一个系统中产生的事件可以通过这种模式让发布者通知所有订阅者。在许多队列系统中常常用主题（topics）这个术语指代发布/订阅模式。在RabbitMQ中，主题就是发布/订阅模式的一种具体实现（更准确点说是交换器（exchange）的一种），但是在这篇文章中，我会把主题和发布/订阅当做等价来看待。

一般来说，订阅有两种类型：

临时（ephemeral）订阅，这种订阅只有在消费者启动并且运行的时候才存在。一旦消费者退出，相应的订阅以及尚未处理的消息就会丢失。

持久（durable）订阅，这种订阅会一直存在，除非主动去删除。消费者退出后，消息系统会继续维护该订阅，并且后续消息可以被继续处理。

RabbitMQ

RabbitMQ作为消息中间件的一种实现，常常被当作一种服务总线来使用。RabbitMQ原生就支持上面提到的两种消息模式。其他一些流行的消息中间件的实现有ActiveMQ，ZeroMQ，Azure Service Bus以及Amazon Simple Queue Service（SQS）。这些消息中间件的实现有许多共通的地方；这边文章中提到的许多概念大部分都适用于这些中间件。

队列

RabbitMQ支持典型的开箱即用的消息队列。开发者可以定义一个命名队列，然后发布者可以向这个命名队列中发送消息。最后消费者可以通过这个命名队列获取待处理的消息。

消息交换器

RabbitMQ使用消息交换器来实现发布/订阅模式。发布者可以把消息发布到消息交换器上而不用知道这些消息都有哪些订阅者。

每一个订阅了交换器的消费者都会创建一个队列；然后消息交换器会把生产的消息放入队列以供消费者消费。消息交换器也可以基于各种路由规则为一些订阅者过滤消息。

RabbitMQ消息交换器

需要重点注意的是RabbitMQ支持临时和持久两种订阅类型。消费者可以调用RabbitMQ的API来选择他们想要的订阅类型。

根据RabbitMQ的架构设计，我们也可以创建一种混合方法——订阅者以组队的方式然后在组内以竞争关系作为消费者去处理某个具体队列上的消息，这种由订阅者构成的组我们称为消费者组。按照这种方式，我们实现了发布/订阅模式，同时也能够很好的伸缩（scale-up）订阅者去处理收到的消息。

发布/订阅与队列的联合使用

Apache Kafka

Apache Kafka不是消息中间件的一种实现。相反，它只是一种分布式流式系统。

不同于基于队列和交换器的RabbitMQ，Kafka的存储层是使用分区事务日志来实现的。Kafka也提供流式API用于实时的流处理以及连接器API用来更容易的和各种数据源集成；当然，这些已经超出了本篇文章的讨论范围。

云厂商为Kafka存储层提供了可选的方案，比如Azure Event Hubsy以及AWS Kinesis Data Streams等。对于Kafka流式处理能力，还有一些特定的云方案和开源方案，不过，话说回来，它们也超出了本篇的范围。

主题

Kafka没有实现队列这种东西。相应的，Kafka按照类别存储记录集，并且把这种类别称为主题。

Kafka为每个主题维护一个消息分区日志。每个分区都是由有序的不可变的记录序列组成，并且消息都是连续的被追加在尾部。

当消息到达时，Kafka就会把他们追加到分区尾部。默认情况下，Kafka使用轮询分区器（partitioner）把消息一致的分配到多个分区上。

Kafka可以改变创建消息逻辑流的行为。例如，在一个多租户的应用中，我们可以根据每个消息中的租户ID创建消息流。IoT场景中，我们可以在常数级别下根据生产者的身份信息（identity）将其映射到一个具体的分区上。确保来自相同逻辑流上的消息映射到相同分区上，这就保证了消息能够按照顺序提供给消费者。

Kafka生产者

消费者通过维护分区的偏移（或者说索引）来顺序的读出消息，然后消费消息。

单个消费者可以消费多个不同的主题，并且消费者的数量可以伸缩到可获取的最大分区数量。

所以在创建主题的时候，我们要认真的考虑一下在创建的主题上预期的消息吞吐量。消费同一个主题的多个消费者构成的组称为消费者组。通过Kafka提供的API可以处理同一消费者组中多个消费者之间的分区平衡以及消费者当前分区偏移的存储。

Kafka消费者Kafka实现的消息模式Kafka的实现很好地契合发布/订阅模式。生产者可以向一个具体的主题发送消息，然后多个消费者组可以消费相同的消息。每一个消费者组都可以独立的伸缩去处理相应的负载。由于消费者维护自己的分区偏移，所以他们可以选择持久订阅或者临时订阅，持久订阅在重启之后不会丢失偏移而临时订阅在重启之后会丢失偏移并且每次重启之后都会从分区中最新的记录开始读取。但是这种实现方案不能完全等价的当做典型的消息队列模式看待。当然，我们可以创建一个主题，这个主题和拥有一个消费者的消费组进行关联，这样我们就模拟出了一个典型的消息队列。不过这会有许多缺点，我们会在第二部分详细讨论。值得特别注意的是，Kafka是按照预先配置好的时间保留分区中的消息，而不是根据消费者是否消费了这些消息。这种保留机制可以让消费者自由的重读之前的消息。另外，开发者也可以利用Kafka的存储层来

