记一次Kafka重复消费解决过程-Toy模板网

这篇具有很好参考价值的文章主要介绍了记一次Kafka重复消费解决过程。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

起因：车联网项目开发，车辆发生故障需要给三个系统推送消息，故障上报较为频繁，所以为了不阻塞主流程，采用了使用kafka。消费方负责推送并保存推送记录，但在一次压测中发现，实际只发生了10次故障，但是推送记录却有30多条。

问题排查，发现是因为其中一个系统宕机，导致往这个系统推送消息时，一直连接超时，导致每条消息的推送时长被拉长。而且kafka消息拉取参数max-poll-records设置了500，意味着一次会批量拉取500条消息到本地处理，而max.poll.interval.ms参数默认是5分钟，当500条消息处理时长超过5分钟后，就会认为消费者死掉了，触发再均衡，导致同一个消息被重复消费。

解决：

主要是提高消费者的处理速度，避免不必要的Rebalance。主要采用2种措施：

减少每次拉去消息数max-poll-records，从500，降到20
拉取到消息之后异步处理（创建线程池，对推送消息的部分利用多线程处理）

常见配置

fetch.min.byte：配置Consumer一次拉取请求中能从Kafka中拉取的最小数据量，默认为1B，如果小于这个参数配置的值，就需要进行等待，直到数据量满足这个参数的配置大小。调大可以提交吞吐量，但也会造成延迟

fetch.max.bytes，一次拉取数据的最大数据量，默认为52428800B，也就是50M，但是如果设置的值过小，甚至小于每条消息的值，实际上也是能消费成功的

fetch.wait.max.ms，若是不满足fetch.min.bytes时，等待消费端请求的最长等待时间，默认是500ms

max.poll.records，单次poll调用返回的最大消息记录数，如果处理逻辑很轻量，可以适当提高该值。一次从kafka中poll出来的数据条数,max.poll.records条数据需要在在session.timeout.ms这个时间内处理完，默认值为500

consumer.poll(100) ，100 毫秒是一个超时时间，一旦拿到足够多的数据（fetch.min.bytes 参数设置），consumer.poll(100)会立即返回 ConsumerRecords<String, String> records。如果没有拿到足够多的数据，会阻塞100ms，但不会超过100ms就会返回

max.poll.interval.ms，两次拉取消息的间隔，默认5分钟；通过消费组管理消费者时，该配置指定拉取消息线程最长空闲时间，若超过这个时间间隔没有发起poll操作，则消费组认为该消费者已离开了消费组，将进行再均衡操作（将分区分配给组内其他消费者成员）

若超过这个时间则报如下异常：

org.apache.kafka.clients.consumer.CommitFailedException: 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.

　　即：无法完成提交，因为组已经重新平衡并将分区分配给另一个成员。这意味着对poll()的后续调用之间的时间比配置的max.poll.interval.ms长，这通常意味着poll循环花费了太多的时间来处理消息。

可以通过增加max.poll.interval.ms来解决这个问题，也可以通过减少在poll()中使用max.poll.records返回的批的最大大小来解决这个问题。

max.partition.fetch.bytes：该属性指定了服务器从每个分区返回给消费者的最大字节数，默认为 1MB。

session.timeout.ms：消费者在被认为死亡之前可以与服务器断开连接的时间，默认是 3s，将触发再均衡操作。

对于每一个Consumer Group，Kafka集群为其从Broker集群中选择一个Broker作为其Coordinator。Coordinator主要做两件事：