kafka consumer客户端消费逻辑解析

kafka consumer客户端消费逻辑解析

一、主要步骤

这是kafka客户端拉取消息的入口,有4个主要部分

1、启动后的准备

consumer线程启动后,如果非自动提交模式,构建worker线程放入worker线程池,供后续消费消息使用

2、运行期逻辑循环------提交策略

3、运行期逻辑循环------消息拉取

4、运行期逻辑循环------消息消费

二、提交策略

【步骤2代码解析】

2.1 在拉取消息之前,如果非自动提交,进行提交判定:

需要提交的消息(ConsumerRecord)会维护在acks------本地已处理待提交消息队列(一个linkedBlockingQueue)中,这里会把acks里所有消息拿出来进行循环处理。

(2-1-1) ack策略-立即提交:说明在配置了手动提交-立即提交的ack策略时,提交动作是每次消息拉取前,worker线程已处理完的消息的offset,挨个put进本地的partition和offset的映射(metadata中一个map)。由于是循环处理worker队列,而消息是乱序存放的,所以put之前判断offset大于现有offset才会执行,确保低offset不覆盖高offset。

put后会直接进行网络请求提交到broker中。(由于在循环中,这里的请求会发生多次?没细看)

(2-1-2) ack策略-非立即提交:

和2-1-1一样,都会维护分区最高位移映射。

接下来会根据具体的提交规则配置来判定是否提交,

1、未提交数:未提交数 >= 配置

2、提交时间间隔:上次提交 - 当前时间 >= 配置

3、未提交数或提交时间间隔:1或2任意满足

【提交策略总结】

一、提交模式

1、自动提交:拉取消息后立即提交

2、手动(非自动)提交:

2-1、拉取消费前执行一次提交判定

二、提交判定

1、立即提交:无需判定

2、非立即提交:根据配置的规则判定

2-1、满足提交时间间隔可提交

2-2、满足未提交数计算可提交

2-3、满足2-1或2-2可提交

三、拉取策略

会循环尝试拉取消息直到超时(最大尝试拉取时长)

四、消费策略

【代码解析】

从待消费消息列表拉取消息,用当前线程或分配给worker线程。worker线程和拉取线程1:1(worker线程为什么不是多个?)

自动提交,用当前线程直接进行消费(可能阻塞消息拉取和位移提交)

手动提交,加入待处理消息队列(一个linkedBlockingQueue),等待消费线程拉取并消费

从待处理消息队列拉取消息,循环进行消费,消费后加入已处理待提交队列

【消费策略总结】

【消费主体】

1、自动提交:consume线程自我消费(会阻塞消息拉取和位移提交)

2、手动提交:worker线程异步消费

【消费模式】

循环消费

相关推荐
灯澜忆梦4 小时前
【minio】#5 | MinIO 分布式部署 + HTTPS 部署
分布式·网络协议·https·对象存储·minio
谢亮_vipxieliang15 小时前
Spring Cloud 服务治理入门:注册发现、配置中心、网关限流、熔断降级与分布式一致性方案
分布式·spring·spring cloud
樱花落木兰1 天前
分布式登录实战:Session 会话共享改造,Redis 存储用户登录状态
java·javascript·数据库·redis·分布式·缓存
ShineWinsu1 天前
对于Redis:Steam、Geospatial、Hyperloglog、Bitmap、Bitfield类型的解析
数据库·c++·redis·分布式·缓存·面试·zset
Flynt2 天前
Redis Cluster主节点挂了,为什么"高可用"还全员掉线?我把三次kill的记录翻出来了
数据库·redis·分布式
JosieBook2 天前
【数据库】MySQL 实战精通系列 · 第10篇:分库分表与分布式事务实战
数据库·分布式·mysql
梦帮科技2 天前
vLLM / TensorRT-LLM 极限推理:PagedAttention 细粒度物理页表管理与连续批处理(Continuous Batching)实战
数据结构·人工智能·分布式·python·深度学习·算法·vllm
用户1494484813202 天前
同为消息队列,RocketMQ 和 Kafka 的底层设计差在哪?
kafka
Frank_refuel2 天前
分布式RPC框架实战(二):服务端模块划分与底层设计
分布式·网络协议·rpc
开开心心就好2 天前
办公软件卸载不干净?专用工具一键清残留
java·前端·人工智能·智能手机·kafka·excel·memcache