雨翔河
首页
列表
关于
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 © 雨翔河
我与我周旋久
独孤影
开源实验室