“田由甲” - Kafka重复消费线上问题暴雷

【“田由甲” - Kafka重复消费线上问题暴雷】的更多相关文章

Kafka重复消费和丢失数据研究

Kafka重复消费原因底层根本原因:已经消费了数据,但是offset没提交. 原因1:强行kill线程,导致消费后的数据,offset没有提交. 原因2:设置offset为自动提交,关闭kafka时,如果在close之前,调用 consumer.unsubscribe() 则有可能部分offset没提交,下次重启会重复消费.例如: try { consumer.unsubscribe(); } catch (Exception e) { } try { consumer.close(); }…

记一次 Kafka 集群线上扩容

前段时间收到某个 Kafka 集群的生产客户端反馈发送消息耗时很高,于是花了一段时间去排查这个问题,最后该集群进行扩容,由于某些主题的当前数据量实在太大,在对这些主题迁移过程中话费了很长一段时间,不过这个过程还算顺利,因为在迁移过程中也做足了各方面的调研,包括分区重平衡过程中对客户端的影响,以及对整个集群的性能影响等,特此将这个过程总结一下,也为双十一打了一剂强心剂. 排查问题与分析接到用户的反馈后,我用脚本测试了一遍,并对比了另外一个正常的 Kafka 集群,发现耗时确实很高,接下来经过排…

elk 使用中遇到的问题（kafka 重复消费）

问题描述: 在使用过程中,当遇到大量报错的时候,我们到eagle后台看到报错的那个consumer的消费情况到到lag 远远大于0(正常情况应该为0),activie 节点没有,kibana面板上没有数据. 因为我们报警使用的是logstash 的email 插件,这里猜测是因为大量的报错,导致email 处理不过来,然后消费进程堵在了email 这里,所以管道堵塞,导致无法消费,所以这里的解决方案是把logstash 的 email 换成 elastialert…

storm调用kafka重复消费的问题

1. 实现IBolt接口的bolt需要显式调用collector.ack(); 2. 继承自BaseBasicBlot的bolt, 会帮你自动调用ack的…

BitArray虽好，但请不要滥用，又一次线上内存暴增排查

一:背景 1. 讲故事前天写了一篇大内存排查在园子里挺火,这是做自媒体最开心的事拉,干脆再来一篇满足大家胃口,上个月我写了一篇博客提到过使用bitmap对原来的List<CustomerID>进行高强度压缩,将原来的List内存压缩了将近106倍,但是bitmap不是一味的好,你必须在正确的场景中使用,而不是闭着眼睛滥用,bitmap在C#中对应的集合是BitArray. 好像剧透了…

kafka重复数据问题排查记录

问题向kafka写数据,然后读kafka数据,生产的数据量和消费的数据量对不上. 开始怀疑人生,以前奠定的基础受到挑战... 原来的测试为什么没有覆盖生产量和消费量的对比? 消费者写的有问题?反复检,无果... 再反过来梳理生产者的代码,检查了几遍,也并无发现疏漏. 开始怀疑Kafka 以前看过文章,说kafka数据有可能重复和丢失数据,难道kafka的这么不精确,丢了这么多数据? 原因最后排查到生产者,kafka生产者使用confluent-kafka-go. 向kafka生产数据的伪代码…

kafka一直rebalance故障，重复消费

今天我司线上kafka消息代理出现错误日志,异常rebalance,而且平均间隔2到3分钟就会rebalance一次,分析日志发现比较严重.错误日志如下 08-09 11:01:11 131 pool-7-thread-3 ERROR [] - commit failed org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already r…