案例描述
在我们现在开发的项目中,经常会用到kafka消息中间件。一般情况下,单线程(单分区)的配置已经可以满足需求,但是在某些大数据和数据并发量要求较高的应用场景下经常会遇到消息来不及处理,出现消息积压的情况。因此,该文章主要针对这种应用场景提供了一个多线程消费的解决方案
案例分析
自己在平时使用kafka消息中间件的时候开始也并没有分区的概念,都是像传统的MQ消息中间件一样,直接从TOPIC里消费消息就行了。但是在有次项目现场发现有时候TOPIC里的消息往往会积压一部分无法消费。后来经过网上查阅资料和阅读kafka官方文档,了解到可以使用kafka提供的多分区能力来解决这个问题。
官网上关于kafka的分区概念介绍很多,我这里总结一下就是:
kafka的分区,相当于把一个TOPIC再细分成了多个通道,一个消费者应用可以从一个通道或者多个通道中获取数据。例如:
- 有4个分区,1个消费者:这一个消费者需要负责消费四个分区的数据
- 有4个分区,2个消费者:每个消费者负责两个分区
- 有4个分区,3个消费者:消费者1负责1个分区,消费者2负责1个分区,消费者3负责2个分区
- 有4个分区,4个消费者:一人一个
- 有4个分区,5个及以上消费者:4个消费者一人一个,剩下的消费者空闲不工作
所以,建议部署的时候尽量做到一个消费者对应一个分区。
具体的实现方案如下:
- 生产者随机分区提交数据
这也是一个比较关键步骤,只有随机提交到不同的分区,才能实现多分区消费;可以自定义自己的分区策略,如下:
public int partition(String topic, Object key, byte[] keyBytes, Object var, byte[] valueBytes