Kakfa 入门到起飞 - 什么是再平衡?什么时候会触发再平衡呢?Kafka为什么遭大家诟病了呢?

Kafka 遭大家诟病了?因为啥?啥是再平衡?

再均衡是Kafka被大家诟病最多的一个点,再平衡是非常麻烦的一个事,那么就让我们来看看

到底什么是再平衡呢?

再平衡其实就是一个 协议,它规定了消费者组下的消费者如何分配主题下的分区
比如:topic有100个分区,一个消费者组内有20个消费者,在coordinator的控制下,一个消费者分配到5个分区,那么这个分配的过程就叫再平衡

那么什么时候会发生再平衡呢?

有3种情况会触发再平衡,

  1. 消费者组内消费者发生变更,增加消费者、减少消费者、消费者宕机退出消费者组等
  2. 主题下分区数发生变更,Kafka当前值支持增加分区,当增加分区时会触发再平衡
  3. 当消费主题数发生变更时,会触发再平衡,

消费主题数变更的情况就是,当消费者组订阅主题通过正则或者通配符的方式,比如topic.*这样,当新增一个主题topic.A,那么相当于这个新增主题下的消息自动被当前消费者组订阅了,需要将分区进行分配,那么就会触发一次再平衡


下面我们逐个情况来看下:比如当前分区分配情况如下图,一个分区一个消费者,均匀分配
在这里插入图片描述

1、运行过程中,consumer4突然宕机,退出消费者组,触发再平衡,此时消费者组中所有消费者都要停下来,将当前4个分区重新分配给剩余3个消费者,这时就会有一个消费者分配到两个分区,如下图所示
在这里插入图片描述

2、运行过程中,有一个broker实例突然宕机,比如分区3所在的broker宕机了,那么分区3的leader分区(Kafka都是leader分区对外提供读写服务)就不可用了,此时会有分区3的副本分区会转换为leader分区继续提供服务的过程,但是只要broker宕机,就会触发再平衡在这里插入图片描述
3、当我们给Topic主题增加一个分区,那么也会触发一次再平衡,比如Topic新增了一个分区4,那么要把分区4分配给一个消费者,如下图在这里插入图片描述

4、消费者通过正则表达式的方式订阅主题,比如topic_//d ,订阅topic_1…topic_9 这样的主题,这时如果新增一个满足条件的主题,也会触发再平衡,如下图在这里插入图片描述


那么为什么大家会诟病再平衡这个事呢?

因为在再平衡过程中,消费者组下的所有消费者需要暂停,无法从Kafka消费消息,这样Kafka的消费能力突然就下来了,如果Kafka集群比较大,几百个节点,那么再平衡会消耗非常多的时间,几分钟到几小时都有可能,这个时间内Kafka基本处于不可用状态


那么在生产中,我们怎么尽量避免发生再平衡呢?

很多情况下broker是误判消费者宕机了,认为服务器宕机了,

在消费者场景中,给我们提供了几个参数可以用来调优,减少Kafka误判的可能性
session.timeout.ms 参数设置,broker端在指定时间内没有收到消费者发送的心跳,那么就认为消费者宕机了,所以在网络不佳的情况下,我们可以将这个值设置的大一些

heartbeat.interval.ms 参数设置,发送心跳的频率,频率设置越高,越不容易被误判,但是不断发送心跳也会消耗更多资源,需要取舍

max.poll.interval.ms 参数设置,消费者每次拉取数据的时间间隔,默认5min 五分钟没有收到消费和拉取数据broker就认为这个消费者宕机了

推荐设置如下:

session.timeout.ms 设置为6s
heartbeat.interval.ms 设置为2s
max.poll.interval.ms 设置为处理消息最长耗时+1min

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
对于选择使用Kafka还是RabbitMQ,需要考以下几个因素: 1. 性能和可扩展性:Kafka是一个高吞吐量、低延迟的分布式消息系统,适用于处理大量实时数据流。RabbitMQ则更适合处理较小规模的消息通信。如果你需要处理大量的数据流,并具备较高的性能和可扩展性需求,那么选择Kafka是更好的选择。 2. 消息持久化:Kafka将所有消息持久化到磁盘上,确保数据不丢失。这对于需要进行数据分析、存储和回溯的场景非常重要。而RabbitMQ默认情况下只将消息存储在内存中,一旦RabbitMQ服务器宕机,消息可能丢失。因此,如果你有持久化消息的需求,Kafka是更适合的选择。 3. 可靠性:Kafka采用分布式、多副本的机制,可以提供较高的可靠性,确保消息不丢失。而RabbitMQ使用AMQP协议,通过确认机制来确保消息的可靠性。这使得RabbitMQ在网络状况不稳定或需要确保消息不丢失的场景下更合适。 4. 简单性和易用性:RabbitMQ相对于Kafka来说更加简单易用,它提供了更多的功能,如消息队列、消息路由、消息确认等,适合快速开发和部署。而Kafka更适合复杂的数据处理和分析场景,但相对于RabbitMQ,它的配置和使用可能更复杂一些。 综上所述,选择Kafka还是RabbitMQ取决于你的具体需求。如果你需要处理大规模的实时数据流,需要较高的性能和可靠性,并且有持久化消息的需求,那么选择Kafka是更好的选择。如果你对可靠性要求不高,希望能够快速部署并且使用较简单的消息通信方式,那么选择RabbitMQ是更合适的。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值