首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >RabbitMQ和Kafka到底怎么选(二)

RabbitMQ和Kafka到底怎么选(二)

作者头像
哲洛不闹
发布2019-05-15 11:35:41
4870
发布2019-05-15 11:35:41
举报
文章被收录于专栏:java一日一条java一日一条

前言

前一篇文章《RabbitMQ和Kafka到底怎么选?》,我们在吞吐量方面比较了Kafka和RabbitMQ,知道了Kafka的吞吐量要高于RabbitMQ。本文从可靠性方面继续探讨两个队列的差异。

RabbitMQ可靠性

我们通过前文知道,RabbitMQ的队列分为master queue和mirror queue,mirror queue 在master queue宕机之后,会被提升为master queue,如下图所示。

队列A的consumer在消费的时候,机器宕机,此时客户端和服务端分别做如下动作:

  • 服务端:把mirror queue提升为master queue
  • 客户端:连接到新的master queue 所在的节点进行消费或者生产

当master queue 所在节点宕机后,其正在被消费的消息的相关信息全部丢失,即服务端不知道消费者对那一瞬间消费的消息是否进行了ACK,所以在mirror queue被提升为master queue时,会把宕机前正在进行消费的的消息全部重新发送一遍,即客户端重连后,消息可能被重复消费,这个时候就必须依靠应用层逻辑来判断来避免重复消费。

在持久化方面,RabbitMQ的master queue每次收到新消息后,都会立刻写入磁盘,并把消息同步给mirror queue。假设在master queue 收到消息后,消息未同步到mirror queue 之前master queue 宕机,则此时mirror queue中就没有刚刚master queue收到的那条消息,当这个mirror queue被提升为master queue时,消费者连接到新的master queue上进行消费时就丢了一条消息。所以,RabbitMQ也会丢消息,只不过这个丢消息的概率非常低。

Kafka可靠性

我们知道Kafka中的每个队列叫做Topic,一个Topic有多个主分片和副分片,当主分片所在机器宕机后,服务端会把一个副分片提升为主分片,如下图所示。

服务端和客户端会有如下动作:

  • 服务端:把副分片提升为主分片
  • 客户端:连接到新的主分片

Kafka同样有主从同步,所以也必定存在与RabbitMQ同样丢消息的问题。但是Kafka的每个客户端保存了读取消息的偏移信息,故当一个主分片宕机后,Kafka客户端可以从副分片相应位移后继续消费,不会有重复消费的情况。

持久化方面,Kafka默认把消息直接写文件,但是由于操作系统的cache原因,消息可能不会立马写到磁盘上,这个时候就需要刷新文件到磁盘。由于刷新文件到磁盘是一个比较耗时的操作,故Kafka提供了两种不同的刷新配置:

我们完全可以把log.flush.interval.messages设置为1,这样Kafka就能在持久化方面达到和RabbitMQ同样的安全级别。

但是Kafka集群依赖ZK,如上图所示,所以对于Kafka稳定性的评估必须考虑ZK集群的稳定性,而一般我们认为任何分布式集群的稳定性都小于1,故两个集群的串联稳定性会下降一些,维护更复杂一些,这点没有RabbitMQ有优势。

总结

其实好多开源组件随着时间推移,往往都进行了各种改进。就比如Kafka虽然是为了日志而生,给人第一印象是容易丢消息,但是经过这么多年的改进,其可靠性可能并不逊色RabbitMQ了,只需要你根据不同的业务场景配置不同的配置参数,即可达到适合自己的安全级别。

  • 从吞吐量上看,在不要求消息顺序情况下,Kafka完胜;在要求消息先后顺序的场景,性能应该稍逊RabbitMQ(此时Kafka的分片数只能为1)。
  • 从稳定性来看,RabbitMQ胜出,但是Kafka也并不逊色多少。
本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-05-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 java一日一条 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • RabbitMQ可靠性
  • Kafka可靠性
  • 总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档