Kafka Consumer多线程消费实战和源码分析

根据官方文档我们知道KafkaConsumer是线程不安全的，KafkaProducer是线程安全的。接下来我们就来讨论为什么KafkaConsumer线程不安全

1、kafka的消费者和分区的关系：

topic下的一个分区只能被同一个consumer group下的一个consumer线程来消费，但反之并不成立，

即一个consumer线程可以消费多个分区的数据，比如Kafka提供的ConsoleConsumer，默认就只是一个线程来消费所有分区的数据。

如图，当consumer1进行一次commit操作时，会同时提交分区0、1的offset信息；

           当consumer2 进行一次commit操作时，只会提交分区2的offset信息；

2、多线程消费kafka数据

     根据消费者和分区关系，在结合多线程具体使用场景有：多线程处理一个消费者只消费一个分区；多线程处理一个消费者消费多个分区。对应模型图为：

2.1 分析场景2

 线程1获得消费者，消费者进行提交操作，然后将分区2的offset+1,完成了本次的提交操作，这里实现了分区和线程关系的绑定，是线程安全的。

代码实现：

2.2 分析场景1

   当线程1获取分区1的数据数据，分区2没有数据时就是场景2的场景不会有任何问题。但是当线程1获取分区1的数据数据，为提交时；线程2获取分区2的数据数据开始消费，这时分区1的offset并没有加1，这里就会有问题了。已做图方式进行解释:

可以看到，当分区数据都被消费后，分区信息的offset应该为（1,1），但实际的分区offset为（1,0）或者（0,1）这个就出现线程不安全问题。

代码实现：

2.2.1 源码分析

Kafka 的consumer有进行一定检查机制，先对进行部分源码分析：

从consumer的subscribe进行分析：

可见首先进行调用acquireAndEnsureOpen()，

根据调用链路可见，当线程1进入，首先获取线程id,然后进行线程id对比。由于初始化线程id为NO_CURRENT_THREAD = -1L;

进行操作1判断，线程id肯定不等于-1。进行操作2，通过一个cas操作，将currenThread的值更新成线程1id;

                               当线程2进行，首先获取线程id,然后进行线程id对比。进行操作1判断，线程2id肯定不等于线程1id，

                                                       进行操作2，通过一个cas操作，发现将currenThread的值为线程1id并不是NO_CURRENT_THREAD 所有抛出异常。

注：根据源码分析，consumer的subscribe和commitSync需要在同一个线程中进行操作，否则会线程异常（之前subscribe我写在主线程中，然后在子线程中commitSync。。。蠢哭了）

 

2.2.2 解决场景1问题

    解决的基本思路：就是在当多线程提交时，每个线程一次只提交自己消费分区的offset，其他分区信息不进行提交。

 

　本例中包含3个类：

 

• ConsumerThreadHandler类：consumer多线程的管理类，用于创建线程池以及为每个线程分配任务。另外consumer位移的提交也在这个类中进行
• ConsumerWorker类：本质上是一个Runnable，执行真正的消费逻辑并上报位移信息给ConsumerThreadHandler
• Main类：测试主方法类
• 
• 
          大神问题解决源码的参考文档：https://www.bbsmax.com/A/l1dyPVY65e/