Kafka作为当下流行的高并发消息中间件,大量用于数据采集,实时处理等场景,我们在享受他的高并发,高可靠时,还是不得不面对可能存在的问题,最常见的就是丢包,重发问题。
- 丢包问题:消息推动服务,每天早上,手机上各终端都会给用户推送消息,这时候流量剧增,可能会出现kafka发送数据过快,导致服务器网卡爆满,或者磁盘处于繁忙状态,可能会出现丢包现象。
解决方案:首先对
kafka
进行限速,其次启用重试机制,重试间隔时间设置长一些,最后Kafka
设置acks=all
。
检测方法:使用重放机制,查看问题所在。
kafka
配置如下:
props.put("compression.type", "gzip"); props.put("linger.ms", "50"); props.put("acks", "all"); props.put("retries ", 30); props.put("reconnect.backoff.ms ", 20000); props.put("retry.backoff.ms", 20000);
- 重发问题:当消费者重新分配partition的时候,可能出现从头开始消费的情况,导致重发问题。当消费者消费的速度很慢的时候,可能在一个session周期内还未完成,导致心跳机制检测报告出问题。
底层根本原因:已经消费了数据,但是offset没提交。
配置问题:设置了offset自动提交
问题场景:
1.设置offset为自动提交,正在消费数据,kill消费者线程;
2.设置offset为自动提交,关闭kafka时,如果在close之前,调用consumer.unsubscribe()
则有可能部分offset没提交,下次重启会重复消费重复消费最常见的原因:
re-balance
问题,通常会遇到消费的数据,处理很耗时,导致超过了Kafka
的session timeout
时间(0.10.x版本默认是30秒),那么就会re-balance
重平衡,此时有一定几率offset
没提交,会导致重平衡后重复消费。去重问题:消息可以使用唯一id标识
Kafka消息保证不丢失和重复消费问题
使用同步模式的时候,有3种状态保证消息被安全生产,在配置为1(只保证写入leader成功)的话,如果刚好leader partition挂了,数据就会丢失。
还有一种情况可能会丢失消息,就是使用异步模式的时候,当缓冲区满了,如果配置为0(还没有收到确认的情况下,缓冲池一满,就清空缓冲池里的消息),
数据就会被立即丢弃掉。
在数据生产时避免数据丢失的方法:
只要能避免上述两种情况,那么就可以保证消息不会被丢失。
就是说在同步模式的时候,确认机制设置为-1,也就是让消息写入leader和所有的副本。
还有,在异步模式下,如果消息发出去了,但还没有收到确认的时候,缓冲池满了,在配置文件中设置成不限制阻塞超时的时间,也就说让生产端一直阻塞,这样也能保证数据不会丢失。
在数据消费时,避免数据丢失的方法:如果使用了storm,要开启storm的ackfail机制;如果没有使用storm,确认数据被完成处理之后,再更新offset值。低级API中需要手动控制offset值。
数据重复消费的情况,如果处理?
(1)去重:将消息的唯一标识保存到外部介质中,每次消费处理时判断是否处理过;
(2)不管:大数据场景中,报表系统或者日志信息丢失几条都无所谓,不会影响最终的统计分析结果。