Kafka-消费者-KafkaConsumer分析总结

KafkaConsumer依赖SubscriptionState管理订阅的Topic集合和Partition的消费状态,通过ConsumerCoordinator与服务端的GroupCoordinator交互,完成Rebalance操作并请求最近提交的offset。

Fetcher负责从Kafka中拉取消息并进行解析,同时参与position的重置操作,提供获取指定Topic的集群元数据的操作。上述操作的所有请求都是通过ConsumerNetworkClient缓存并发送的,在ConsumerNetworkClient中还维护了定时任务队列,用来完成HearbeatTask任务和AutoCommitTask任务。NetworkClient在接收到上述请求的响应时会调用相应回调,最终交给其对应的*Handler以及RequestFuture的监听器进行处理。

KafkaConsumer并不是一个线程安全的类。为了防止多线程并发操作,KafkaConsumer提供了多线程并发的检测机制,涉及的方法是acquire和release。这两个方法的代码如下:


我们可以看出,这并不是一种锁的实现,仅实现了检测多线程并发操作的检测。这里使用CAS操作可以保证线程之间的可见性。CAS操作、可见性等相关概念请参考Java并发专栏

面我们来分析KafkaConsumer.poll方法进行消息消费的整个流程以及相关代码:

注意,在消费完消息之后,客户端还需要commit offset,手动同步commit offset使用commitSync(),手动异步commit offset使用commitAsync(),自动commit offset使用定时任务AutoCommitTask。

在pollOnce方法中会先通过ConsumerCoordinator与GroupCoordinator交互完成Rebalance操作,之后从GroupCoordinator获取最近一次提交的offset(或重置position),最后才是使用Fetcher,从Kafka获取消息进行消费。

相关推荐
棠十一5 小时前
Rabbitmq
分布式·docker·rabbitmq
Lansonli5 小时前
大数据Spark(六十一):Spark基于Standalone提交任务流程
大数据·分布式·spark
Theodore_10227 小时前
大数据(2) 大数据处理架构Hadoop
大数据·服务器·hadoop·分布式·ubuntu·架构
Wo3Shi4七10 小时前
Kafka综合运用:怎么在实践中保证Kafka_高性能?
后端·kafka·消息队列
G探险者12 小时前
《深入理解 Nacos 集群与 Raft 协议》系列五:为什么集群未过半,系统就不可用?从 Raft 的投票机制说起
分布式·后端
G探险者12 小时前
《深入理解 Nacos 集群与 Raft 协议》系列一:为什么 Nacos 集群必须过半节点存活?从 Raft 协议说起
分布式·后端
G探险者12 小时前
《深入理解 Nacos 集群与 Raft 协议》系列四:日志复制机制:Raft 如何确保提交可靠且幂等
分布式·后端
G探险者12 小时前
《深入理解 Nacos 集群与 Raft 协议》系列三:日志对比机制:Raft 如何防止数据丢失与错误选主
分布式·后端
G探险者12 小时前
《深入理解 Nacos 集群与 Raft 协议》系列二:Raft 为什么要“选主”?选主的触发条件与机制详解
分布式·后端
Vesan,14 小时前
网络通讯知识——通讯分层介绍,gRPC,RabbitMQ分层
网络·分布式·rabbitmq·无人机