关于kafka消费慢的一次记录

背景：

多个生产者组向kafka发送消息，每个生产者每次发送消息数量不定。消费者收到消息后进行判断后写文件。

事件：

程序日志中时不时出现：

Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing. You can address this either by increasing the session timeout or by reducing the maximum size of batches returned in poll() with max.poll.records. 

原因 ：

原因很明显就是由于消费能力跟不上，导致了kafka消息积压，查看积压情况，十分严重

分析： 

只是简单的判断和写文件，没有复杂的业务逻辑，不应该消费慢啊？

1、想到会不会是由于只有两个分区，生产者的key相同消息只分发到一个分区中导致积压呢？查看发送消息的代码发现key是处理过的不会相同，排除该猜测。

2、看消费端吧，由于数据多怕消费慢所以将消息poll了之后放入一个队列中，队列大小设置的是10万，然而这个10万就是罪魁祸首！因为我们的数据有时候一次就大于10万，这个队列放不下，消费端更无法去poll下一批数据，就会导致消息积压。于是修改队列长度大小，服务器允许的话就无界，不允许的话就给个合理的以免造成OOM。

ConsumerRecords<String, byte[]> records = consumer.poll(60000);
records.forEach(record -> {
                        LinkedBlockingQueue<KafkaBean> queue = eventIdMap.get(record.key());
                        if(queue == null) {
                            queue = new LinkedBlockingQueue<>(100000);
                        }
                });