还在纠结Kafka 和 RabbitMQ用哪个?一篇文章告诉你他们的区别

本文详细分析了Kafka和RabbitMQ在消息顺序、消息匹配、消息超时、消息保持、消息错误处理和吞吐量六个场景的差异。在订单状态变化消息广播中,Kafka的发布订阅、顺序保证和吞吐量表现优于RabbitMQ。在复杂消息匹配需求下,RabbitMQ的灵活性胜出。而在消息超时和事件溯源场景,Kafka的消息持久化特性更具优势。对于消息错误处理,RabbitMQ的容错机制较Kafka更友好。在大多数项目中,Kafka的大吞吐量可能并非必需,RabbitMQ的易用性和维护成本更低。建议根据具体业务需求选择合适的消息队列。
摘要由CSDN通过智能技术生成

经常有人问我

有个 xx 需求,我应该用 Kafka 还是 RabbitMQ ?

这个问题很常见,而且很多人对二者的选择也把握不好。

所以我决定写篇文章来详细说一下:Kafka 和 RabbitMQ 的区别,适用于什么场景?

同时,这个问题在面试中也经常问到。

下面我会通过 6 个场景,来对比分析一下 Kafka 和 RabbitMQ 的优劣。

一、消息的顺序

有这样一个需求:当订单状态变化的时候,把订单状态变化的消息发送给所有关心订单变化的系统。

订单会有创建成功、待付款、已支付、已发货的状态,状态之间是单向流动的。

好,现在我们把订单状态变化消息要发送给所有关心订单状态的系统上去,实现方式就是用消息队列。

在这种业务下,我们最想要的是什么?

  1. 消息的顺序:对于同一笔订单来说,状态的变化都是有严格的先后顺序的。

  2. 吞吐量:像订单的业务,我们自然希望订单越多越好。订单越多,吞吐量就越大。

在这种情况下,我们先看看 RabbitMQ 是怎么做的。

首先,对于发消息,并广播给多个消费者这种情况,RabbitMQ 会为每个消费者建立一个对应的队列。也就是说,如果有 10 个消费者,RabbitMQ 会建立 10 个对应的队列。然后,当一条消息被发出后,RabbitMQ 会把这条消息复制 10 份放到这 10 个队列里。

当 RabbitMQ 把消息放入到对应的队列后,我们紧接着面临的问题就是,我们应该在系统内部启动多少线程去从消息队列中获取消息。

如果只是单线程去获取消息,那自然没有什么好说的。但是多线程情况,可能就会有问题了……

RabbitMQ 有这么个特性,它在官方文档就声明了自己是不保证多线程消费同一个队列的消息,一定保证顺序的。而不保证的原因,是因为多线程时,当一个线程消费消息报错的时候,RabbitMQ 会把消费失败的消息再入队,此时就可能出现乱序的情况。

T0 时刻,队列中有四条消息 A1、B1、B2、A2。其中 A1、A2 表示订单

  • 2
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值