Kafka - Kafka 消费者 + 再平衡Rebalance
一、kafka消费方式
kafka采取pull（拉）模式
二、消费者总体工作流程
老版本0.9之前，offset保存在zookeeper上。
新版本1.0后，每个消费者的offset又消费者提交到系统主题保存。
三、消费者组原理
3.1 原理简介
3.2 消费者组初始化过程
四、消费者API
4.1 独立消费者案例
1）消费者消费某主题 - subscribe()
代码示例：
2）消费者消费某主题的特定分区 - assign()
下图，展示该消费者，消费first主题，指定的0号分区
4.2 消费者组案例
三个消费者，都是在test消费者组中
五、分区分配策略 + 再平衡
请参加更佳详细专业的博客：【kafka】Kafka消费者分区分配策略详解
以下截图是B站讲解，讲了个大概，不详细。
5.1 Range策略 - 针对每个topic
正常情况
再平衡策略
前提：session.timeout.ms = 45, 一旦消费者和coordinators失去联系超过45s，该消费者就会下线
情况1：当消费者0突然下线，但还没超时45s 时，且此时发送者又发送了数据。此时分区0，1，2的数据无法抵达消费者0,也不会去消费者consumer 1，consumer 2。但等过了45s后，0，1，2分区的数据会全部涌进消费者consumer 1里。
情况2：当消费者0下线超过45s，会被下线。消费者只剩下consumer 1，consumer 2. 如果此时发送者发送数据，这时剩下的两个消费者会重新划分分区：consumer 1 接受 0，1，2，3；consumer 2 接受 4，5，6 。
5.2 RoundRobin策略 - 针对所有topic
正常情况
再平衡策略
情况1：当消费者1突然下线，但还没超时45s 时，且此时发送者又发送了数据。此时分区0，3，6的数据无法抵达消费者0, 也不会去消费者consumer 2，consumer 3。但等过了45s后，0，3，6这三个分区依然遵循轮询的办法，把0，6分区放进其中一个consumer，3分区去另一个consumer。
情况2：当消费者1下线超过45s，会被下线。消费者只剩下consumer 2，consumer 3. 如果此时发送者发送数据，这时剩下的两个消费者会重新划分分区：consumer 2 接受 0，2，4，6；consumer 3 接受 1，3，5 。
5.3 Sticky策略
所以如果使用默认的轮询partition策略，可能会造成一个大的batch被轮询成多个小的batch的情况，鉴于小batch可能导致延时增加。鉴于此，kafka2.4的时候推出一种新的分区策略，即StickyPartitioning Strategy，StickyPartitioning Strategy会随机地选择另一个分区并会尽可能地坚持使用该分区——即所谓的粘住这个分区。该策略是一种全新的策略，能够显著地降低给消息指定分区过程中的延时。使用StickyPartitioner有助于改进消息批处理，减少延迟，并减少broker的负载。
分区的分配要尽可能的均匀，分配给消费者者的主题分区数最多相差一个；
分区的分配尽可能的与上次分配的保持相同。
可以看到，虽然range和sticky都是分成了三组3-2-2组合，但是range是先排序再分组，而sticky是随机的
再平衡策略
情况1：当消费者1突然下线，但还没超时45s 时，且此时发送者又发送了数据。45s内没反应。但等过了45s后，会把下线消费者原本负责的分区，均匀随机分给其他消费者。
情况2：当消费者1下线超过45s，会被下线。消费者只剩下consumer 2，consumer 3. 如果此时发送者发送数据，...会把所有的分区，重新均匀随机分给存活的消费者。
可以看到，情况2重新分配时，consumer 0 依然保持着原来的1，4分区；consumer2 依然保留 2，5分区...黏上了！
5.4 CooperativeSticky 策略 - 再平衡时不必放弃原有分区
六、offset位移
6.1 offset的默认维护位置？
kafka 0.9版本之前，offset保存在zookeeper里。
kafka 0.9版本开始，offset默认保存在一个系统主题_consumer_offsets里面。
如何查看系统主题consumer_offsets呢？
默认情况下，是不能查看的。
6.2 自动提交offset
6.3 手动提交offset
自动提交offset虽然方便，但是可能出现提前消费的情况 -- 即消费者已经消费到5号了，但是offset保存的还是2号，因为还没到5s，所以还未更新offset。
6.4 指定offset消费
红色框注意：得等3.2小节的示意图1-6步骤完成，才能拿到分区情况：
6.5 指定时间消费
6.6 漏消费 与 重复消费
如何解决该问题，实现“精准一次性消费”？ -- 消费者事务
详细内容之后再讲。
6.7 数据积压（kafka集群 -- 消费者端）
生产者端 -- kafka集群
参考之前文章：https://www.cnblogs.com/frankcui/p/16065365.html#_label4
kafka集群 -- 消费者端
方法2要注意kafka默认每批次最大50M，如果修改消费者一次拉去条数后超过了50M，要记得去修改50M这个配置
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布：重大改进与新特性概览！
· AI与.NET技术实操系列（二）：开始使用ML.NET
· 单线程的Redis速度为什么快？