记一次Kakfa消费者集群的生产事故

因为一次 Kafka 宕机引发的高可用问题,我明白了 Kafka 高可用原理! Kafka宕机引发的高可用问题 问题要从一次Kafka的宕机开始说起。 所在的是一家金融科技公司,但公司内部并没有采用在金融支付领域更为流行的RabbitMQ,而是采用了设计之初就为日志处理而生的Kafka,所以我一直很好奇Kafka的高可用实现和保障。从Kafka部署后,系统内部使用的Kafka一直运行稳定,没有出现不可用的情况。 但最近系统测试人员常反馈偶有Kafka消费者收不到消息的情况,登陆管理界面发现三个节点中有一个节点宕机挂掉了。但是按照高可用的理念,三个节点还有两个节点可用怎么就引起了整 阅读详情

由于项目业务需要,在之前的Kafka Consumer集群的自动提交设置为手动提交,先介绍一下怎么设置为手动提交。

设置手动提交

consumer

@Component
public class KafkaConsumer {

    @Autowired
    private CustomConfig customConfig;

    @Autowired
    private StatsDClient statsDClient;

    @Value("${spring.kafka.bootstrap-servers}")
    private String kafkaBootstrapServer;

    @Value("${spring.kafka.sfc-bootstrap-servers}")
    private String kafkaSfcServer;

    @Value("${spring.kafka.consumer.group-id}")
    private String kafkaGroupId;

    @Autowired
    private GPSKafkaConfig gpsKafkaConfig;

    @Value("${spring.kafka.consumer.enable-auto-commit}")
    private Boolean autoCommit;

    @Value("${spring.kafka.consumer.auto-commit-interval}")
    private Integer autoCommitMs;


    @Value("${spring.kafka.listener.ack-count}")
    private Integer ackCount;

    @Value("${spring.kafka.listener.ack-time}")
    private Integer ackTime;



    private Map<String, Object> initProps() {
        Map<String, Object> props = new HashMap<>();
        
        // kafka的ip地址
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, kafkaBootstrapServer);

        props.put(ConsumerConfig.GROUP_ID_CONFIG, kafkaGroupId);
        props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, autoCommit);
        props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, autoCommitMs);

        props.put(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG, gpsKafkaConfig.getSessionTimeoutMs());
        props.put(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, gpsKafkaConfig.getMaxPollIntervalMs());

        props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, gpsKafkaConfig.getMaxPollRecords());
        props.put(ConsumerConfig.FETCH_MIN_BYTES_CONFIG, gpsKafkaConfig.getFetchMinBytes());
        props.put(ConsumerConfig.FETCH_MAX_WAIT_MS_CONFIG, gpsKafkaConfig.getFetchMaxWaitMs());

        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);

        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, kafkaBootstrapServer);

        return props;
    }


    @Bean("customContainerFactory")
    public ConcurrentKafkaListenerContainerFactory customContainerFactory() {
        ConcurrentKafkaListenerContainerFactory factory = new ConcurrentKafkaListenerContainerFactory();
        factory.setConsumerFactory(new DefaultKafkaConsumerFactory(initProps()));
        factory.setConcurrency(gpsKafkaConfig.getGpsConcurrency());
        factory.setBatchListener(true);


        // 改为手动提交必须设置的参数,否则会报错

        // 设置手动提交的模式
        //RECORD:每处理一条commit一次
        //BATCH(默认):每次poll的时候批量提交一次,频率取决于每次poll的调用频率
        //TIME:每次间隔ackTime的时间去commit
        //COUNT:累积达到ackCount次的ack去commit
        //COUNT_TIME:ackTime或ackCount哪个条件先满足,就commit
        //MANUAL:listener负责ack,但是背后也是批量上去
        //MANUAL_IMMEDIATE:listner负责ack,每调用一次,就立即commit  

factory.getContainerProperties().setAckMode(AbstractMessageListenerContainer.AckMode.MANUAL);
        // 当ackMode为“COUNT”或“COUNT_TIME”时,偏移提交之间的记录数
        factory.getContainerProperties().setAckCount(ackCount);
        // 当ackMode为“TIME”或“COUNT_TIME”时,偏移提交之间的时间(以毫秒为单位)
        factory.getContainerProperties().setAckTime(ackTime);
        
        return factory;
    }


    @KafkaListener(topics = {"消费的topic名称"}, containerFactory = "customContainerFactory")
    public void orderMessage(String message,Acknowledgment ack) {
        
        // 你的业务

        // 执行结束,手动提交
        ack.acknowledge();
    }

}

Config

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;


@ConfigurationProperties(prefix = "spring.kafka.custom")
@Configuration
@Data
public class GPSKafkaConfig {
    /**
     * kafka消费线程数
     */
    private Integer gpsConcurrency;
    /**
     * 允许自动提交
     */
    private Boolean enableAutoCommit;
    /**
     * 自动提交时间
     */
    private Integer autoCommitIntervalMs;
    /**
     * session.timeout.ms
     */
    private Integer sessionTimeoutMs;
    /**
     * max.poll.interval.ms
     */
    private Integer maxPollIntervalMs;
    /**
     * 返回的最大record数
     */
    private Integer maxPollRecords;

    /**
     * 一个parttion拉取的最小字节数
     */
    private Integer fetchMinBytes;
    /**
     * 拉取数据的时候最长等待时间,与fetch.min.bytes配合使用
     */
    private Integer fetchMaxWaitMs;

    private Integer abandonPercent;

    /**
     * 顺风车丢弃gps消息比例
     */
    private Integer sfcAbandonPercent;
}

YML 

  kafka:
    listener:
      #当enable-auto-commit为false时生效
      ack-mode: manual
      #当ackMode为“COUNT”或“COUNT_TIME”时,偏移提交之间的记录数
      ack-count: 10
      #当ackMode为“TIME”或“COUNT_TIME”时,偏移提交之间的时间(以毫秒为单位)
      ack-time: 10000
      concurrency: 50
    bootstrap-servers: xx.xx.xx.xx:9092
    consumer:
      enable-auto-commit: false
      auto-commit-interval: 100
      group-id: group1
      auto-offset-reset: latest
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
    custom:
      gpsConcurrency: 120
      enableAutoCommit: false
      autoCommitIntervalMs: 100
      sessionTimeoutMs: 300000
      maxPollIntervalMs: 500000
      maxPollRecords: 50
      fetchMinBytes: 51200
      fetchMaxWaitMs: 2000
      abandonPercent: 10

消费者集群改为手动提交引发的问题

1、如果不是单台机器,是集群的,那么会有分片问题

commit failed 
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.
        at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.sendOffsetCommitRequest(ConsumerCoordinator.java:713) ~[MsgAgent-jar-with-dependencies.jar:na]
        at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.commitOffsetsSync(ConsumerCoordinator.java:596) ~[MsgAgent-jar-with-dependencies.jar:na]
        at org.apache.kafka.clients.consumer.KafkaConsumer.commitSync(KafkaConsumer.java:1218) ~[MsgAgent-jar-with-dependencies.jar:na]
        at com.today.eventbus.common.MsgConsumer.run(MsgConsumer.java:121) ~[MsgAgent-jar-with-dependencies.jar:na]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_161]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_161]
        at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161]

这个错误的意思是,消费者在处理完一批poll的消息后,在同步提交偏移量给broker时报的错。初步分析日志是由于当前消费者线程消费的分区已经被broker给回收了,因为kafka认为这个消费者死了,那么为什么呢?

问题分析

这里就涉及到问题是消费者在创建时会有一个属性max.poll.interval.ms,
该属性意思为kafka消费者在每一轮poll()调用之间的最大延迟,消费者在获取更多记录之前可以空闲的时间量的上限。如果此超时时间期满之前poll()没有被再次调用,则消费者被视为失败,并且分组将重新平衡,以便将分区重新分配给别的成员。

分析原因

如下是我们消费者处理逻辑(省略部分代码)

 while (isRunning) {
            ConsumerRecords<KEY, VALUE> records = consumer.poll(100);
            if (records != null && records.count() > 0) {
           
            for (ConsumerRecord<KEY, VALUE> record : records) {
                dealMessage(bizConsumer, record.value());
                try {
                    //records记录全部完成后,才提交
                      consumer.commitSync();
                } catch (CommitFailedException e) {
                      logger.error("commit failed,will break this for loop", e);
                        break;
                }
            }
}

poll()方法该方法轮询返回消息集,调用一次可以获取一批消息。

kafkaConsumer调用一次轮询方法只是拉取一次消息。客户端为了不断拉取消息,会用一个外部循环不断调用消费者的轮询方法。每次轮询到消息,在处理完这一批消息后,才会继续下一次轮询。但如果一次轮询返回的结构没办法及时处理完成,会有什么后果呢?服务端约定了和客户端max.poll.interval.ms,两次poll最大间隔。如果客户端处理一批消息花费的时间超过了这个限制时间,服务端可能就会把消费者客户端移除掉,并触发rebalance。

拉取偏移量与提交偏移量

kafka的偏移量(offset)是由消费者进行管理的,偏移量有两种,拉取偏移量(position)与提交偏移量(committed)。拉取偏移量代表当前消费者分区消费进度。每次消息消费后,需要提交偏移量。在提交偏移量时,kafka会使用拉取偏移量的值作为分区的提交偏移量发送给协调者。
如果没有提交偏移量,下一次消费者重新与broker连接后,会从当前消费者group已提交到broker的偏移量处开始消费。
所以,问题就在这里,当我们处理消息时间太长时,已经被broker剔除,提交偏移量又会报错。所以拉取偏移量没有提交到broker,分区又rebalance。下一次重新分配分区时,消费者会从最新的已提交偏移量处开始消费。这里就出现了重复消费的问题。

解决方案

1.增加max.poll.interval.ms处理时长

kafka消费者 默认此间隔时长为300s,本次故障是300s都没处理完成,于是改成500s。

max.poll.interval.ms=500000

2.设置分区拉取阈值

kafkaConsumer调用一次轮询方法只是拉取一次消息。客户端为了不断拉取消息,会用一个外部循环不断调用轮询方法poll()。每次轮询后,在处理完这一批消息后,才会继续下一次的轮询。

max.poll.records = 50

3.poll到的消息,处理完一条就提交一条,当出现提交失败时,马上跳出循环,这时候kafka就会进行rebalance,下一次会继续从当前offset进行消费。

 while (isRunning) {
            ConsumerRecords<KEY, VALUE> records = consumer.poll(100);
            if (records != null && records.count() > 0) {
           
            for (ConsumerRecord<KEY, VALUE> record : records) {
                dealMessage(bizConsumer, record.value());
                try {
                    //records记录全部完成后,才提交
                      consumer.commitSync();
                } catch (CommitFailedException e) {
                      logger.error("commit failed,will break this for loop", e);
                        break;
                }
            }
}
Kafka消费者卡死问题:消费组无响应、Topic无写入数据,实际上有数据可用 然而,有时候会遇到消费者卡死的情况,即消费组无响应,导致Kafka中的Topic无法写入数据,尽管实际上有可用的数据。本文将介绍一些可能导致此问题的常见原因,并提供相应的代码示例以解决这个问题。在使用Apache Flink和Kafka进行大数据处理时,消费者卡死和Topic无写入数据是常见的问题。本文介绍了可能导致这些问题的原因,并提供了相应的解决方法。通过正确配置消费者、提高处理速度和处理消费者异常终止,可以解决这些问题,并确保数据的正常流动。 阅读详情

相关推荐

PLC期末速成——顺序功能图转梯形图

一、根据顺序功能图写出梯形图程序 顺序功能图: 梯形图: 1、程序段1,系统运行标志M0.0的启-保-停控制电路。 2、程序段2,PLC上电与逆行,初始化脉冲M1.0激活初始化步M2.0。 3、程序段3,当M2.0初始化步为活动步,并且M0.0系统运行标志位为1时,置位M2.1步,复位M2.0步。 4、当M2.1为活动步,并且I0.3中液位传感器为1时,置位M2.2步,复位M2.1步。 5、程序段5,当M2.2为活动步,并且I0.2高液位传感器为1时,置位M2.3步,复位M2.2步。 6、程序段

qq_52251819的博客 1万+

正确处理kafka多线程消费的姿势

最近项目开发过程使用kafka作为项目模块间负载转发器,实现实时接收不同产品线消息,分布式准实时消费产品线消息。通过kafka作为模块间的转换器,不仅有MQ的几大好处:异步、解耦、削峰等几大好处,而且开始考虑最大的好处,可以实现架构的水平扩展,下游系统出现性能瓶颈,容器平台伸缩增加一些实例消费能力很快就提上来了,整体系统架构上不用任何变动。理论上,我们项目数据量再大整体架构上高可用都没有问题。...

Johnnie Zhang的专栏 2万+

AD24层次原理图设计避坑指南:如何解决端口连接与自动交叉引用问题

本文深入解析AD24层次原理图设计的核心机制,聚焦端口连接错误、自动交叉引用干扰等常见问题。通过对比自上而下与自下而上设计流程,提供端口类型匹配、命名规范等实用解决方案,并指导如何关闭烦人的红色框线视觉干扰,帮助工程师高效避坑,实现复杂系统的模块化设计。

wdx01234567的博客 615

Kafka及Kafka消费者的消费问题及线程问题

kafka消费与线程池遇到的问题分析

胡买提 6031

基于计算机视觉的Windows自动化工具openclaw-win:从原理到实战

计算机视觉与自动化技术正深刻改变人机交互方式,其核心在于让机器具备“感知-决策-执行”的能力。通过图像采集与处理算法,程序可以识别屏幕上的特定元素;结合模拟输入技术,便能自动执行点击、拖拽等操作,形成完整的自动化闭环。这一技术栈在软件测试、数据采集、重复性办公任务等领域具有重要价值,能够显著提升工作效率。开源项目openclaw-win正是这一理念的工程实践,它整合了图像识别与模拟操作模块,为开发者提供了一个研究自动化技术的具体样本。项目涉及模板匹配、坐标计算等关键技术点,并需处理屏幕适配、操作延迟等实际问

weixin_28745975的博客 330

生成式引擎优化(GEO)标准化操作流程:构建高效AI生成系统的全链路指南

GEO是针对生成式AI的内容优化策略,通过提升内容在AI生成答案中的引用优先级实现品牌传播。相比传统SEO,GEO使内容直接嵌入AI答案,无需用户点击链接。核心流程包括:1)逆向拆解AI问答场景,结构化知识资产;2)生产权威内容(白皮书、专利数据)和算法适配内容(PCOE模板);3)技术实现(数据投喂、模型微调);4)331渠道分发策略;5)效果监控与动态防御。需注意采用结构化数据标记、主动提交训练数据,并避免简单复制SEO策略。2025版强调内容权威性和语义优化,通过AI原生内容工程实现高效曝光。

解锁AI流量新红利!🚀 GEO优化(生成引擎优化)助您掌控AI搜索,让AI成为您的品牌最佳代言人! 1161

关于与kafka的爱恨交织

我们在项目中使用到了kafka,但是后面发生的一系列事让我更加深刻去了解kafka,在前一段时间线上kafka一直出现一个问题消息堆积一直不消费, 重启服务后开始消费? 生产环境kafka在消费一段时间后,停止消费,服务重启后又继续开始消费,但是隔一段时间又会重复出现这个问题。后面在查阅大量资料后,总结出来这几种可能及解决方法,希望可以帮到有相同情况的朋友。 这种情况应该是最多的也是最有可能的,网上查询也大多说的这个原因,完全符合我上面描述的情况,其实也很简单,无非就是发生了Rebalance。

时光的博客 4778

GitLab社区版vs企业版:本地部署性能对比与选型建议(含实测数据)

本文深入对比GitLab社区版(CE)与企业版(EE)在本地部署中的性能差异与功能特性,提供实测数据与选型建议。测试显示EE版在并发克隆、CI流水线启动等场景性能提升显著,尤其适合需要高级安全合规与CI/CD功能的团队。文章还包含硬件配置指南与成本效益分析,帮助技术决策者做出明智选择。

weixin_28828243的博客 295

从Kafka的一次broker假死介绍Kafka架构和DefaultPartitioner

最近公司的kafka集群出现了节点已经失效但是节点进程和端口都还在的情况,目前我们的系统监控只是做到了进程监控,即为整个集群的每台机群建立进程快照,如果进程(如NameNode、kakfa broker)丢失,则报警并立刻自动重启进程。但是这次的kafka事故进程和端口都还在,因此报警系统没有能够及时报警,因此对此次事故发生的过程和解决方式做详细的分析。 首先,我们一个同学使用kafka的过程中发...

小昌昌的博客 3848

从后端角度浅谈抗辐射设计----三模冗余(TMR)

三模冗余设计(TMR),是最常用的一种容错技术,三个模块采取相同的操作,以多数相同的输出作为表决系统的正确输出,即3取2,因为三个模块是相互独立的,而其中两个模块同时出错的概率是极小的,因此便可保证系统输出的可信度。然而这个设计也会存在面积浪费,功耗的增加,而且由于是冗余的设计,在后续进行综合或者pr的时候会被工具优化,因此需要对模块进行don’t touch设置;通过增值表得到,逻辑关系表达式为:Q=(Q1&Q2)|(Q1&Q3)|(Q2&Q3),通过工艺库的stdcell进行搭建,得到如下电路。

芯冰乐 327

【AI智能体】Dify 基于知识库搭建智能客服问答应用详解

Dify 基于知识库搭建智能客服问答应用详解

congge 6929

RocketMQ第1讲——初始篇

今天开始就系统的学习和总结下消息队列,市面上消息队列的设计基本八九不离十,我对RocketMQ相对熟悉一点,所以就从RocketMQ入手,在知晓RocketMQ的大体设计后对其它消息队列也就手到擒来了。

让~学习~成为一种习惯(橡 皮 人の技术博客) 998

【OS】AUTOSAR OS系统调用产生Trap的过程详解

AUTOSAR OS系统调用产生Trap的过程详解

qq_36056498的博客 2438

消息队列 Kafka\RocketMq

mq

JaweG 2066

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

spring boot 集成kafka (多线程,消费者使用kafka的原生api实现,因为@KakfkaListener修改groupId无效)

原文链接:http://www.mamicode.com/info-detail-2078498.html 1 #kafka 2 kafka.consumer.zookeeper.connect=*:2181 3 kafka.consumer.servers=*:9092 4 kafka.consumer.enable.auto.commit=true 5 kafka.consumer...

qq_40633152的博客 8879

STM32F407中文手册

STM32f407中文手册 本参考手册面向应用开发人员,提供有关使用 STM32F405xx/07xx、STM32F415xx/17xx、 STM32F42xxx 和 STM32F43xxx 微控制器存储器与外设的完整信息。STM32F405xx/07xx、STM32F415xx/17xx、STM32F42xxx 和 STM32F43xxx 构成一个微 控制器系列,各产品具有不同的存储器大小、封装和外设。有关订购信息以及器件的机械与电气特性,请参见数据手册。有关 ARM Cortex™-M4F 内核的信息,请参见《Cortex™-M4F 技术参考手册》。

spring-kafka消费线程加载过程分析

因为最近遇到spring-kafka消费线程中断消费的问题,所以看了它消费线程的启动过程,来总结一下。 Lifecycle和SmartLifecycle 要想知道它的加载过程,首先要先了解这两个接口: Lifecycle是Spring中最基础的生命周期接口,该接口定义了容器启动和停止的方法。 SmartLifecycle是对Lifecycle的一个扩展接口,相比Lifecycle增加以下功能: 无需容器显示调用start()方法,就可以回调SmartLifecycle接口的start() 容器中如果有多个

huangdi1309的博客 2137

kafka消费者提交offset时卡住

服务端 kafka_2.11-1.0.1 客户端 kafka-clients-1.0.1 在断网等情况下,程序会停止在consumer.commitSync(final Map<TopicPartition, OffsetAndMetadata> offsets)这个方法上。 是因为默认的超时时间为Long.MAX_VALUE 意味着消费者会一直不停的尝试提交offset,只到发生一些unrecoverable(不可恢复的)异常。比如 服务器返回提交失败、线程中断、权限验证失败等 ...

w363403269的专栏 1508

分布式 - 消息队列Kafka:Kafka分区常见问题总结

如果某个 Broker 上的领导者分区数量超过了平均值的 10%,则该 Broker 将不再接受新的领导者分区,直到其他 Broker 上的领导者分区数量增加,使得整个集群的领导者分区数量平衡。比如很多公司使用 Kafka 收集应用服务器的日志数据,这种数据都是很多的,特别是对于那种大批量机器组成的集群环境,每分钟产生的日志量都能以 GB 数,因此如何将这么大的数据量均匀地分配到 Kafka 的各个 Broker 上,就成为一个非常重要的问题。并且,我们还可以通过添加新的节点机器来增加整体系统的吞吐量。

你今天真好看呀 2643

记一次线上kafka造成的事故

比如,当前生产者的offset为1000,消费者的offset为100,此时想要直接消费offset为1000的数据,然后修改消费者端的offset为1000,然后消费者提交了1000,但是消费者还在继续消费啊,下次消费完就又向生产者提交了自己的offset101了,于是就又消费了老的数据。方案2:mysql的删除操作为持续操作一直在进行,被删除的数据一直在向kafka中生产,即使重置offset也无法解决问题。但是重置offset需要先关闭消费组消费,最好kill 掉,或者重新换个消费组。

java_xxxx的博客 1165

Kafka 老司机忠告:请停止这样使用 @KafkaListener!

但实际上,水面之下还有很多门道,比如:怎么处理错误、什么时候该重试、消息顺序怎么保证、offset(消费位点)什么时候提交、一次能处理多少条消息等等。你只要加上一个注解,把它连到一个 topic 上,然后“嗖”的一下,它就跟变魔术似的开始工作了。如果你的消息体结构发生变化(比如,生产者那边给 JSON 加了个新字段),默认的反序列化器可能会直接抛出。),但如果我们不加小心,满足于表面的简单,最终可能会陷入各种难以排查的问题中。这能确保在发生重平衡或应用关闭时,消费者能更平稳地过渡,减少对业务的影响。

郑龙飞 1578

Springboot整合Kafka-自动,手动提交偏移量

本篇记录一下消息的提交方式,默认的消费位移提交的方式是自动提交的,这个由消费者客户端参数enable.auto.commit控制,默认为true,默认的自动提交不是每消费一条消息就提交一次,而是定期的提交,这个定期的周期时间由客户端参数auto.commit.interval.ms配置,默认为5秒,此参数生效的前提是enable.auto.commit参数为true。自动提交消费位移的方式非常简便,它免去了复杂的位移提交逻辑,让编码更简洁。但随之而来的是重复消费和消息丢失的问题。那重复消费和消息丢失的问..

FAIRYTAIL的博客 1万+

Kafka “假死“现象深度解析与解决方案

Kafka假死(也称为"僵死"或"挂起")是指Kafka集群或Broker在表面上进程仍在运行,但实际上已经停止响应或处理能力极度下降的状态。生产者消息无法写入(超时)消费者无法拉取消息管理API无响应监控指标停止更新但进程仍在系统进程中可见资源隔离:专用磁盘、独立ZK集群合理配置:根据硬件调整线程池和超时参数全面监控:覆盖从硬件到应用层的指标应急预案:制定详细的恢复流程预防胜于治疗。通过合理的容量规划、定期的压力测试和完善的监控体系,可以显著降低假死风险。

weixin_43680337的博客 1391

记一次宕机造成的flink消费Kafka topic失败问题

kafka报错:Error while fetching metadata with correlation id 72 :{topic=LEADER_NOT_AVAILABLE}

好记性不如烂笔头 1139

记一次kafka消费延迟造成的生产问题

背景介绍 今天有同事找我,说他那边遇到kafka消费延迟问题,某条消息从生产者发送后,再到消费者收到,经过了几分钟的时间,之后又恢复正常,时不时会遇到一次这样的问题。 简单分析 当我一听到消费延迟的问题,很自然的就想到了肯定消息阻塞造成的,所以我首先我们查看了消息队列的消费情况,发现当前并没有消息积压在kafka服务端,之后我们也确认了kafka集群很正常,没有出现任何异常现象。 进一步分析 虽然表面上看消息并没有积压,但凭借经验,我感觉还是这方面的问题,既然kafka服务端自身没有积压,那一定就是消费端自

自律使我自由 2475

MQ——Kafka消费者原理

摘要 与生产者对应的是消费者,应用程序可以通过KafkaConsumer 来订阅主题,并从订阅的主题中拉取消息。不过在使用KafkaConsumer消费消息之前需要先了解消费者和消费组的概念,否则无法理解如何使用KafkaConsumer。本章首先讲解消费者与消费组之间的关系,进而再细致地讲解如何使用KafkaConsumer。 消费者与消费组 消费者(Consumer)负责订阅Kafka中的主题(Topic),并且从订阅的主题上拉取消息。与其他一些消息中间件不同的是:在Kafka的消费理念中还有一层

庄小焱 2945

【kafka】kafka报Commit cannot be completed since the group has already rebalanced and assigned the part

Springboot整合kafka 报错 Commit cannot be completed since the group has already rebalanced and assigned the partitions。

DreamSun的博客 2522
上一篇: RestTemplate Https请求忽略SSL证书
下一篇: Kafka设定时段消费消息
CarsonBigData
博客等级 码龄9年 8315粉丝 166原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值