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获取消息进行消费。