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获取消息进行消费。
原文地址:https://blog.csdn.net/zhuyufan1986/article/details/135743171
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_60789.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
