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

avatar
作者
筋斗云
阅读量:0

文章收录在网站: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分钟。

广告一刻

为您即时展示最新活动产品广告消息,让您随时掌握产品活动新动态!