Kafka知识总结(消费者+重平衡)

文章收录在网站:http://hardyfish.top/

文章收录在网站:http://hardyfish.top/

文章收录在网站:http://hardyfish.top/

文章收录在网站:http://hardyfish.top/

在这里插入图片描述

消费者

消费者策略

RangeAssignor:默认消费者策略。

对一个消费者组来说,消费方式是以分区总数除以消费者总数来决定,如果不能整除,往往是从头开始将剩余的分区分配。

在这里插入图片描述

RoundRobinAssignor:对于同一组消费者来说,使用轮训的方式来决定消费者消费的分区,既依次分配一个,直到分区被分配完毕。

在这里插入图片描述

StickyAssignor,是在0.11.x新增的,保证分配最大程度地平衡,同时保留尽可能多的现有分区分配。

意思就是前面两个当同组内有新的消费者加入或者旧的消费者退出的时候,会从新开始决定消费者消费方式,但是Sticky在同组中有新的消费者加入或者旧的消费者退出时,不会直接开始重构分配策略,而是保留现有消费者消费策略,将退出的消费者所消费的分区平均分配给现有消费者,新增消费者同理,同其他现存消费者的消费策略中分离。

CooperativeStickyAssignor,它继承了StickyAssignor的逻辑,但允许重构分区策略。

Push和Pull

Kafka消费端是通过主动拉取消息的方式来消费的。

消费者组

Consumer Group是指组内有多个消费者或消费者实例,它们共享一个公共的 ID,这个 ID 被称为 Group ID。组内的所有消费者协调在一起来消费订阅主题的所有分区。

Consumer Group 下可以有一个或多个 Consumer 实例。

Group ID 是一个字符串,在一个 Kafka 集群中,它标识唯一的一个 Consumer Group。

Consumer Group 下所有实例订阅的主题的单个分区,只能分配给组内的某个 Consumer 实例消费,这个分区也可以被其他的 Group 消费。

点对点模型和发布/订阅模型

如果所有实例都属于同一个 Group,那么它实现的就是消息队列模型;如果所有实例分别属于不同的 Group,那么它实现的就是发布/订阅模型。

Consumer实例个数

理想情况下,Consumer 实例的数量应该等于该 Group 订阅主题的分区总数。

位移主题

Consumer 的位移管理机制就是将 Consumer 的位移数据作为一条条普通的 Kafka 消息,提交到 __consumer_offsets 中。

__consumer_offsets 的主要作用是保存 Kafka 消费者的位移信息。它要求这个提交过程不仅要实现高持久性,还要支持高频的写操作。

位移主题怎么被创建的?

当 Kafka 集群中的第一个 Consumer 程序启动时,Kafka 会自动创建位移主题。

位移主题的分区由 Broker 端参数 offsets.topic.num.partitions 设置,默认值是 50,因此 Kafka 会自动创建一个 50 分区的位移主题。

副本数由 Broker 端参数 offsets.topic.replication.factor 设置,它的默认值是 3。

怎么提交位移?

提交位移的方式有两种:自动提交位移和手动提交位移。

Consumer 端有个参数叫 enable.auto.commit,如果值是 true,则 Consumer 在后台默默地定期提交位移,提交间隔由一个参数 auto.commit.interval.ms 来控制。

问题:只要 Consumer 一直启动着,它就会无限期地向位移主题写入消息。

假设 Consumer 当前消费到了某个主题的最新一条消息,位移是 100,之后该主题没有任何新消息产生,故 Consumer 无消息可消费了,所以位移永远保持在 100。

由于是自动提交位移,位移主题中会不停地写入位移 =100 的消息。

Kafka 使用 Compact 策略来删除位移主题中的过期消息,避免该主题无限期膨胀。

Kafka 提供了专门的后台线程定期巡检待 Compact 的主题,看看是否存在满足条件的可删除数据。后台线程叫 Log Cleaner

重平衡

Rebalance 本质上是一种协议,规定了一个 Consumer Group 下的所有 Consumer 如何达成一致,来分配订阅 Topic 的每个分区。

比如某个 Group 下有 20 个 Consumer 实例,它订阅了一个具有 100 个分区的 Topic。正常情况下,Kafka 平均会为每个 Consumer 分配 5 个分区。这个分配的过程就叫 Rebalance。

Rebalance的触发条件:

组成员数发生变更:比如有新的 Consumer 实例加入组或者离开组。

订阅主题数发生变更。

订阅主题的分区数发生变更:当分区数增加时,就会触发订阅该主题的所有 Group 开启 Rebalance。

在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待 Rebalance 完成

可能发生Rebalance的场景

1、未能及时发送心跳,导致 Consumer 被踢出Group而引发的。

#单位ms 设置心跳传送时间几毫秒一次 ,默认是3000ms
heartbeat.interval.ms

#单位ms 多长时间没有心跳,后连接超时,默认10000ms
session.timeout.ms

2、Consumer消费时间过长导致的,默认10分钟。

  • 17
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Kafka消费者试机制可以通过建立一个专门用于试的topic(retry topic)来实现。当消费者没有正确消费一条消息时,将该消息转发(发布)到试主题(retry topic)上,并提交消息的偏移量,以便继续处理下一个消息。这个时候,这个没有正确消费的消息,对于这个消费者来说,也算是消费完成了,因为也正常提交了偏移量,只不过是业务没有正确处理,而且这个消息被发布到另一个topic中了(retry topic)。之后再创建一个消费者,用于订阅这个试主题,只不过这个消费者,跟之前那个消费者处理相同的业务,两个逻辑是一样的。如果这个消费者也无法消费这条消息,那就把这个消息发布到另一个试主题上,并提交该消息的偏移量。循环,递归。最后,当创建了很多消费者的时候,在最终消费者无法处理某条消息后,把该消息发布到一个死信队列(DLQ)。 ```shell # 代码示例 # 创建一个专门用于试的topic bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic retry_topic # 消费者处理消息时,如果出现异常,将消息转发到试主题上 # 代码示例 try: # 处理消息的业务逻辑 except Exception as e: # 将消息转发到试主题上 producer.send('retry_topic', value=message.value, key=message.key) # 创建一个消费者,用于订阅试主题 # 代码示例 consumer = KafkaConsumer('retry_topic', bootstrap_servers=['localhost:9092'], group_id='retry_group') for message in consumer: try: # 处理消息的业务逻辑 except Exception as e: # 将消息转发到另一个试主题上 producer.send('retry_topic_2', value=message.value, key=message.key) # 提交消息的偏移量 consumer.commit() # 将无法处理的消息发布到死信队列 # 代码示例 producer.send('dead_letter_queue', value=message.value, key=message.key) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值