kafka 消费者线程安全问题详细探讨
内容概要
主要内容
常见错误案例
下面这段代码大概逻辑
-
初始化时实例化KafkaConsumer, 开启线程拉取消息并且处理 -
资源释放回调停止线程、调用kafkaConsumer.close进行资源释放
表面上没有问题，但实际上可能出现线程安全问题，因为poll 和 close 两个操作可能同时执行,因此存在线程安全问题, 如何修改，读者自己思考下。
@PostConstructpublic void consumer(){kafkaConsumer = new KafkaConsumer(getConfig());kafkaConsumer.subscribe(Arrays.asList("test_partition_num"));new Thread(new Runnable() {@Overridepublic void run() {while(running){ConsumerRecords<String,String> records = kafkaConsumer.poll(Duration.ofMillis(1000));records.forEach(record->{System.out.println(" partition =" + record.partition() +" offset = " + record.offset() + " value = " + record.value());});}}}).start();}@PreDestroypublic void close(){running = false;if(kafkaConsumer != null){kafkaConsumer.close();}}
消费者非线程安全代码解读
kafka生成者是线程安全的，但消费者是非线程安全的。KafkaConsumer
-
相关操作前
-
调用acquire()方法，校验线程安全问题，如果发现其他线程也在操作，则直接抛出异常。
-
-
操作完成后
-
调用release()清除痕迹
-
acquire()相对于加锁，release()相当于释放锁。
参看poll 方法实现，一目了然。
private void acquire() {long threadId = Thread.currentThread().getId();if (threadId != this.currentThread.get() && !this.currentThread.compareAndSet(-1L, threadId)) {throw new ConcurrentModificationException("KafkaConsumer is not safe for multi-threaded access");} else {this.refcount.incrementAndGet();}}private void release() {if (this.refcount.decrementAndGet() == 0) {this.currentThread.set(-1L);}}
poll源码
如何实现消费者多线程消费消息呢
思路1
每次实例化一个 KafkaConsumer
这种方式实现简单，但每次都需要建立TCP 链接
思路2
相关操作方法 加上 synchronized,获取使用Lock 加锁保证线程安全
这种方式性能较差
思路3
拉取消息使用一个线程， 消息处理使用多线程
因为通常拉取消息比较快，消息处理比较耗时，由于消息处理不涉及KafkaConsumer 相关API 操作，因此不存在线程安全问题。这种方式建议消息位移设置自动提交，否则编程复杂度较高。
示例代码
ConsumerRecords<String,String> records = kafkaConsumer.poll(Duration.ofMillis(1000));executorService.execute(()->{//处理消息records.forEach(record->{System.out.println(" partition =" + record.partition() +" offset = " + record.offset() + " value = " + record.value());});
});旁敲侧击 举一反三
面试题回顾 Dubbo 线程模型
通常我们线程分为两类
-
IO 线程：负责网络通信的读写操作，接收和发送请求与响应。
-
业务线程：处理具体的业务逻辑，避免因业务处理耗时过长而阻塞 IO 线程。
Dubbo 线程模型有几种你还记得否？该如何选择？
-
AllDispatcher：所有消息都派发到线程池，包括请求、响应、连接事件、断开事件、心跳等。
-
DirectDispatcher：所有消息都不派发到线程池，全部在 IO 线程上直接执行。
-
MessageOnlyDispatcher：只有请求和响应消息派发到线程池，其它连接断开、心跳等消息直接在 IO 线程上执行。
-
ExecutionDispatcher：只把请求消息派发到线程池，响应和其它连接、断开、心跳等消息直接在 IO 线程上执行。
其实选择的依据 业务处理的快慢，如果业务处理很快则建议让业务处理逻辑放到 IO线程中执行，这样避免线程上下文切换影响性能。反之则处理逻辑需要放到具体的业务线程中执行。
一般来说业务执行需要查询数据库，绝大数场景建议使用默认的 AllDispatcher
是不是又和我一起温故知新了，加油吧 少年 ！！！