雨翔河
首页
列表
关于
kafka 重复消费问题的排查过程
2018-12-05 12:12
在压力测试过程中，请求的峰值一直持续的时候就容易出现了大量的XX字段插入失败，唯一键冲突。 检查日志能发现出现大量的提交到kafka失败 ``` Commit cannot be completed due to group rebalance ``` 很多次提交到kafka都是rebalance，为什么发生了rebalance 我们的应用是开三个线程消费kafka消息，拿到消息后就会进行提交，理论上是不应该出现这种情况的。 > kafka 版本在1.0之前是通过客户端poll消息的间隔来判断客户端是否挂掉，1.0 版本改为用单独的线程维持心跳判断是否挂掉。 这个重复消费的集群使用kafka客户端是用的0.9的版本，这就意味着是通过poll消息的间隔来判断是否挂掉。 当poll下消息处理时间超过30秒的时候就会导致发生rebalance，提交失败，紧接着别的机器又消费到了这批消息。 其次，我们把kafka的session超时时间设置由原来的30秒改为了90秒，也就是说间隔时间超过90秒才会rebalance。 改变之后问题不再发生重复消息的情况， 但是日志刷新有卡顿的情况，也就是说有什么逻辑操作卡住了线程，且这个卡住过程特别长，已经不是正常的范围。 由于压测环境暂时没有安装 ` pinpoint `，所以只能自己去看代码打了几个关键点的日志计算处理时间。 果然发现在高并发的情况下两个insert的sql操作耗时居然长达 30s+ ，初步怀疑是这个测试环境的oracle的数据库存在IO问题。 将库切换到另外一台oracle机器，发现insert操作非常快，原来第一台oracle的机器是虚拟机部署的，在这样的高并发下，根本不够看。。。 最终： 将耗时操作的insert的那个库切换到实体机oracle。 > 同时最重要的是将服务端和客户端的kafka升级到1.0版本，让kafka使用单独的心跳线程来维持心跳规避掉这种问题。
类型：工作
标签：kafka,rebalance,java
Copyright © 雨翔河
我与我周旋久
独孤影
开源实验室