IT袋

当前位置:主页 > 对比评测 >

Kafka和RabbitMQ到底怎么选

Kafka和RabbitMQ到底怎么选?(3)

时间:2024-03-24 12:00:26 来源:IT袋 作者:马勇
导读:Kafka和RabbitMQ到底怎么选,再看下 Kafka 的: Kafka 要实现延迟队列就很麻烦了。 你先需要把消息先放入一个临时的 topic。 然后得自己开发一个做中转的消费者。让这个中间的消费者

Kafka和RabbitMQ到底怎么选

Kafka和RabbitMQ到底怎么选

再看下 Kafka 的:

Kafka和RabbitMQ到底怎么选

Kafka 要实现延迟队列就很麻烦了。

  • 你先需要把消息先放入一个临时的 topic。
  • 然后得自己开发一个做中转的消费者。让这个中间的消费者先去把消息从这个临时的 topic 取出来。
  • 取出来,这消息还不能马上处理啊,因为没到时间呢。也没法保存在自己的内存里,怕崩溃了,消息没了。所以,就得把没有到时间的消息存入到数据库里。
  • 存入数据库中的消息需要在时间到了之后再放入到 Kafka 里,以便真正的消费者去执行真正的业务逻辑。
  • ……

想想就已经头大了,这都快搞成调度平台了。再高级点,还要用时间轮算法才能更好更准确。

这次,RabbitMQ 上那一条条戴手表的消息,才是最好的选择。

四、消息的保持

在微服务里,事件溯源模式是经常用到的。如果想用消息队列实现,一般是把事件当成消息,依次发送到消息队列中。

事件溯源有个最经典的场景,就是事件的重放。简单来讲就是把系统中某段时间发生的事件依次取出来再处理。而且,根据业务场景不同,这些事件重放很可能不是一次,更可能是重复 N 次。

假设,我们现在需要一批在线事件重放,去排查一些问题。

RabbitMQ 此时就真的不行了,因为消息被人取出来就被删除了。想再次被重复消费?对不起。

而 Kafka 呢,消息会被持久化一个专门的日志文件里。不会因为被消费了就被删除。

所以,对消息不离不弃的 Kafka 相对用过就抛的 RabbitMQ,请选择 Kafka。

五、消息的错误处理

很多时候,在做记录数据相关业务的时候,Kafka 一般是不二选择。不过,有时候在记录数据吞吐量不大时,我自己倒是更喜欢用 RabbitMQ。

原因就是 Kafka 有一个我很不喜欢的设计原则:

当单个分区中的消息一旦出现消费失败,就只能停止而不是跳过这条失败的消息继续消费后面的消息。即不允许消息空洞。

只要消息出现失败,不管是 Kafka 自身消息格式的损坏,还是消费者处理出现异常,是不允许跳过消费失败的消息继续往后消费的。

所以,在数据统计不要求十分精确的场景下选了 Kafka,一旦出现了消息消费问题,就会发生项目不可用的情况。这真是徒增烦恼。

而 RabbitMQ 呢,它由于会在消息出问题或者消费错误的时候,可以重新入队或者移动消息到死信队列,继续消费后面的,会省心很多。

坏消息就像群众中的坏蛋那样,Kafka 处理这种坏蛋太过残暴,非得把坏蛋揪出来不行。相对来说,RabbitMQ 就温柔多了,群众是群众,坏蛋是坏蛋,分开处理嘛。

六、消息的吞吐量

Kafka 是每秒几十万条消息吞吐,而 RabbitMQ 的吞吐量是每秒几万条消息。

其实,在一家公司内部,有必须用到 Kafka 那么大吞吐量的项目真的很少。大部分项目,像 RabbitMQ 那样每秒几万的消息吞吐,已经非常够了。

在一些没那么大吞吐量的项目中引入 Kafka,我觉得就不如引入 RabbitMQ。

为什么呢?

因为 Kafka 为了更好的吞吐量,很大程度上增加了自己的复杂度。而这些复杂度对项目来说,就是麻烦,主要体现在两个方面:

1、配置复杂、维护复杂

Kafka 的参数配置相对 RabbitMQ 是很复杂的。比如:磁盘管理相关参数,集群管理相关参数,ZooKeeper 交互相关参数,Topic 级别相关参数等,都需要一些思考和调优。

另外,Kafka 本身集群和参与管理集群的 ZooKeeper,这就带来了更多的维护成本。Kafka 要用好,你要考虑 JVM,消息持久化,集群本身交互,以及 ZooKeeper 本身和它与 Kafka 之间的可靠和效率。

2、用好,用对存在门槛

Kafka 的 Producer 和 Consumer 本身要用好用对也存在很高的门槛。

比如,Producer 消息可靠性保障、幂等性、事务消息等,都需要对 KafkaProducer 有深入的了解。

而 Consumer 更不用说了,光是一个日志偏移管理就让一大堆人掉了不少头发。

相对来说,RabbitMQ 就简单得多。你可能都不用配置什么,直接启动起来就能很稳定可靠地使用了。就算配置,也是寥寥几个参数设置即可。

所以,大家在项目中引入消息队列的时候,真的要好好考虑下,不要因为大家都鼓吹 Kafka 好,就无脑引入。

总结

可以看到,如果我们要做消息队列选型,有两件事是必须要做好的:

  1. 列出业务最重要的几个特点
  2. 深入到消息队列的细节中去比较

等我们对这些中间件的特点非常熟悉之后,甚至可以把业务分解成不同的子业务,再根据不同的子业务的特征,引入不同的消息队列,即消息队列混用。这样,我们就可能会最大化我们的获益,最小化我们的成本。

说了这么多,其实还有很多 Kafka 和 RabbitMQ 的比较没有说,比如二者集群的区别,占用资源多少的比较等。以后有机会可以再提提。

总之,期待大家看完这篇文章后,能对 Kafka 和 RabbitMQ 的区别有了更细节性的了解。

最后,分享一个网上的比较全的对比图:

Kafka和RabbitMQ到底怎么选

相关阅读