九师兄

文章讨论了在使用Kafka消费者API时，获取分区偏移量（offset）时可能遇到的超时问题。作者在代码中使用了position方法来获取分区的偏移量，但未设置超时时间，导致程序在某些情况下卡死。通过分析Kafka的源码，作者发现position方法在获取偏移量时会阻塞，直到确定位置或超时。超时时间由default.api.timeout.ms配置项决定，默认值为60000毫秒（60秒）。作者建议在调用position方法时显式设置超时时间，以避免因网络问题或服务器响应延迟导致的程序卡死。

我们flink消费kafka报错Kafka have leader brokers without a matching listener我们这个报错主要是对方的kafka5个节点，然后崩溃了2个，而我们的topic是，正常情况下，每个分区是在一台机器上均匀分布，但是现在他们崩了2个，导致这两台机器上的topic区分缺失了2个，然后因为没有副本，然后就报错了。

报错信息 “this server does not host this topic-partition” 表明在尝试删除 Kafka 主题时，服务器无法找到相应的主题分区。是这样的我使用kafka 2.3版本，然后使用api删除topic，然后执行报错this server does not host this topic-partition，这个意思是找不到相应的topic。我们的情况是我们是web界面展示topic，所以topic一定是有的，但是不清楚为何会报错这个，可能是同时有别人删除了。

然后他的kafka集群有5台机器，挂了2台，然后他们把kerberos都先关闭了，但是挂的怎么都无法重启成功。20231228日，我负责的一个现场环境，整个环境中病毒了，毒性很深，30多台机器全崩溃的，而且是kerberos认证的环境。而且这个环境有个神奇的地方，重新创建这个topic会报错，提示topic已经存在，但是你又查不到这个topic。因为上面原因，我们消费数据有问题，然后我们消费数据的时候出现问题，因此我就打算重建topic，步骤如下。后面运维手动处理了一下元数据，才呢个查出来。

具体的详情报错如下这个错误表明在 Kafka 客户端应用程序中存在身份验证问题。错误涉及到 Java Security API 和 Simple Authentication and Security Layer (SASL) 机制，具体提到了一个 GSSException，其消息为 “No valid credentials provided” 和 “Clock skew too great”。：在身份验证过程中 SASL 机制遇到错误时抛出的异常。

message.timestamp.difference.max.ms=9223372036854775807： 定义了消息时间戳之间的最大差异，这里是没有限制。min.compaction.lag.ms=0： 定义了触发日志紧凑（compaction）的最小延迟时间，这里是0毫秒。segment.index.bytes=10485760： 定义了每个日志段的索引文件的大小，这里是10 MB。file.delete.delay.ms=60000： 定义了删除文件的延迟时间，这里是60秒。

解决这个问题的一种方法是确保你的系统上有符合要求的libstdc++.so.6版本。你可以使用系统包管理工具来安装它，具体的命令可能因你使用的Linux发行版而异。在Linux系统中，libstdc++.so.6是C++标准库的共享对象文件，而GLIBCXX_3.4.21是其特定版本。这可能是由于库的版本不匹配导致的问题。另外，你也可以考虑使用更新版本的snappy-java库，因为新版本可能解决了这种依赖关系问题。确保你使用的snappy-java版本与你的应用和系统兼容。现在升级到最新版本试试。

我们先启动一个kafka然后控制台生成和消费数据然后在写个代码的生产和消费然后测试类如下并且都运行起来，然后我们生产一些数据然后我们可以看到都能正常的消费然后我们暴力删除数据这个命令执行后，我们的代码消费立即停止了然后我们的生产者都是好的然后我们不该消费组的情况下是直接报错的改了消费组，一样的报错但是控制台是可以正常消费的，控制台也是每次一个新的消费组呀。

flink 消费kafka,之前任务正常的，突然有个分区没法消费了，重启下任务久正常了。

排查问题的时候，我们要做删除topic，然后重启kafka，但是发现其他节点都重启的很快，但是有台机器启动很慢，而且日志卡着了。卡的很久，都不见新的日志，但是前面是没有报错的。这个一看就是在加载索引文件，但是我们最后整整等了20分钟才加载好，但是其他机器很快，这个不清楚是为什么差距这么大。如果日志段文件损坏，可能导致加载失败。然后我们打开这个server节点的debug日志，然后可以看到日志中一直打印DEBUG日志。发现这个日志里面有600多G的数据，然后查看其他启动快的机器，发现只有300G左右。

原因说明：因为在kafka1.x以后，启用幂等后，kafka服务端会缓存producer发来的最近5个request的元数据，故无论如何，都可以保证最近5个request的数据都是有序的。=1（不需要考虑是否开启幂等性）。需要设置小于等于5。

正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某 些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡。

压缩后的offset可能是不连续的，比如上图中没有6，当从这些offset消费消息时，将会拿到比这个 offset 大的 offset 对应的消息，实际上会拿到 offset 为 7 的消息，并从这个位置开始消费。​ 这种策略只适合特殊场景，比如消息的 key 是用户 ID，value 是用户的资料，通过这种压缩策略，整个消息集里就保存了所有用户最新的资料。超过设置的所有日志总大小，阐述最早的 segment。Kafka 中默认的日志保存时间为 7 天，可以通过调整如下参数修改保存时间。

kafka消费报错：Offsets out of range with no configured reset policy for partitions报错原因：当消费者消费offset大于或小于当前kafka集群的offset值时，消费会报错比如场景一：一个consumer group消费某topic，当consumer group间隔几天不消费，Kafka内部数据会自动清除之前的数据，程序再次启动时，会找之前消费到的offset进行消费，此时，若Kafka已经删除此offset值，就会产生此报错。

因为这个环境是已经存在的，以前的kafka容器是1.0版本，但是现在要验证一个新的环境kafka 3.6.0。我不想重新做，然后我想直接在flink1里面直接安装kafka 3.6版本。然后把kafka的端口映射打开，将kafka内部的9194端口，映射到外面的19194端口。我这个flink版本是1.13.0，然后kafka版本是3.6.0,然后报错的。然后进行消费，可以看到可以正常的进行消费。在docker容器内进行生产和消费。先记录一下这个问题吧。首先说一下这个环境特征。这个问题之前出现的。

如果你的 Kafka topic 没有配置副本（replicas），而且挂掉的节点是包含主分区（leader）的机器，那么可能会对可用性和数据的持久性产生严重影响。重平衡： 当 Kafka 消费者组成员发生变化时（例如，某个消费者实例启动或关闭），可能会触发消费者组的重平衡。当一个没有副本的主分区所在的机器（也就是 leader 所在的机器）挂掉时，这会导致主分区不可用，因为没有备份。在这种情况下，如果没有配置副本，一旦主分区的机器挂掉，相关数据将不可访问，除非你能够修复挂掉的机器或者重新启动这个主分区。

利用数据库唯一键约束可以利用我们的乐观锁插入消费记录不丢和不重是矛盾的（在分布式场景下），总的来说，开发者根据业务的实际需求来选择相应的方式即可。

Kafka如何保证消息不丢失？Kafka通过Producer、Broker和Consumer这三个角度来保证消息不丢失。

一个consumer group 中有多个 consumer 组成， 一个 topic 有多个 partition 组成，现在的问题是，到底由哪个 consumer 来消费哪个 partition 的数据。Kafka 有四种主流的分区分配策略：Range、RoundRobin、Sticky、CooperativeSticky。可以通过配置参数 partition.assignment.strategy，修改分区的分配策略。默认策略是 Range+ CooperativeSticky。

一个环境搞成了高可用环境，然后故意挂掉一台，然后想看看数据是否还能正常的写入和消费。kafka的topic详情如下，挂掉的是1001对应的机器。然后尝试控制台写入报错报错信息显示在请求元数据超时时，批处理中包含的记录已过期。这可能是由于停止了一台机器导致集群的状态发生变化，导致生产者无法及时获取到更新的元数据信息。当生产者发送消息时，它需要获取关于主题和分区的元数据信息，以确定消息应该发送到哪个分区。如果生产者无法及时获取到最新的元数据信息，就会出现超时异常。

检查 Kafka 版本：确保您使用的 Kafka 版本与您的应用程序和其他依赖项兼容，并根据需要升级 Kafka 版本。由于一个分区可能会被分成多个段，每个段有不同的起始和结束偏移量。Kafka 版本不兼容：可能存在 Kafka 版本不兼容或升级过程中出现了一些问题。配置错误：某些配置参数可能不正确，导致无法正确处理 FetchRequest 请求。检查配置参数：检查 Kafka 配置文件中与分区相关的配置参数，确保它们正确设置。数据损坏：分区中的数据文件可能已损坏，导致无法正确读取分段信息。

最近做了一个kafka监控，然后发现报错了，错误信息如下但是查看topic是正常的。

某环境FLink无法连接kafka,然后报错如下查看topic详情是正常的。调整也没有作用。查看 kafka 偏移量 ，好像没有这个消费组，说明没有创建在服务器上控制台消费数据，发现是正常的最后telnet发现网络不通最终发现配的虽然是IP，但是kafka返回的是host。

给定一个长度为偶数的数组arr，长度记为2*N。前N个为左部分，后N个为右部分。arr就可以表示为请将数组调整成的样子。

最近看一个kafka集群出问题了，然重启又如下日志具体如下这里想看看这是为什么。

我们今天遇到一个问题，同一个topic名称叫topic_lcc，这个topic同时被Flink消费和web客户端消费，但是flink消费没有报错（也可能设置忽略报错了），web端消费报错，错误信息如下2.源码分析在最前的的readHeader中报错默认有这四种报错我们可以运行已有的测试类根据以前的测试类：【kafka】kafka NoSuchElementException ArrayDeque getLast 压缩方式不同kafka 生产者和服务器才能压缩kafka生产者压缩是把压缩方式写在头

其实是对方kafka是个集群，但是他们只提供了一个ip给我们，然后只开了这个ip的网络策略。所以有些数据发送失败，有些成功[捂脸哭]这个问题我曾经遇到过类似的，但是这个博客找不到了，哪个博客里面描述的是，一个kafka集群，然后对方不让我们直接访问，而是给我们一个代理机器，然后我们访问代理机器，由代理机器转发，但是有问题，下次找到补个链接。

但是上面那个图也说明数据量确实大了，后来发现他们此时有人正在备份数据库。然后他就以为 2ms一下子新增了 241405433条数据。关键是此时消费者的服务器就来了巨量的流量。

今天要升级kafka客户端版本，我们的服务端版本是1.1.0，然后客户端版本要升级到kafka 2.8.2，有点不明白公司为啥死都不升级服务端版本，使劲升级客户端版本。今天升级后发现这里面的代码不能使用了，然后需要升级。

场景：消费kafka写入hdfs时，要从spark任务迁移为flink任务消费，为保证不丢数据，用同一个groupid消费数据flink消费数据，提交不了offset到kafka，报错如下原因：kafka的消费模式分为此种场景会发生standalone consumer（assign()消费模式）与consumer group冲突。

要想了解这个问题该怎么解决，首先我们要明白，导致kafka 重复消费的原因有哪些？这个首先看MQ的一般情况，什么情況会导致消息被重复消费呢?生产者：生产者可能会重复推送一条数据到 MQ 中，比如 Controller接口被重复调用了2次，没有做接口幂等性导致的；MQ：在消费者消费完准备响应 ack 消息消费成功时，MQ 突然挂了，导致MQ 以为消费者还未消费该条数据，MQ 恢复后再次推送了该条消息，导致了重复消费。

因为这个环境是已经存在的，以前的kafka容器是1.0版本，但是现在要验证一个新的环境kafka 3.6.0。我不想重新做，然后我想直接在flink1里面直接安装kafka 3.6版本。然后把kafka的端口映射打开，将kafka内部的9194端口，映射到外面的19194端口，然后在宿主机上查看端口。可以看到kafka端口是通的，zk端口也是通的，但是生产的时候报错，而且一直没找到解决方案。发现端口映射已经正常了。然后写了一个代码进行验证。然后进行消费，可以看到可以正常的进行消费。首先说一下这个环境特征。

你这个broker不是krait模式的，启动的时候看看配置文件是不是指定错了。我以为是我的问题，后来验证我写了一个普通的消费者链接的时候任然报错。但是Flink消费的时候报错。然后再次生产和消费就可以了。docker构建方式如下。很多人漏了kraft。后面运维更改了模式如下。

今天在群里遇到这样一个问题：flink 消费2个kafka topic a,b，状态成功保存在savepoint，途中删掉一个topic a，运行一会再把这个topic a加回来，这时候这个topic a 的状态就无法读取了，会重新消费, 但是偏移量是还保存在kafka _consumer_offsets 里面，有没有办法能让他继续从之前的offset 消费呢？这个问题，我们先拆分一下。

左图为 Kafka 现有架构，元数据在 zookeeper 中，运行时动态选举 controller，由controller 进行 Kafka 集群管理。右图为 kraft 模式架构（实验性），不再依赖 zookeeper 集群，而是用三台 controller 节点代替 zookeeper，元数据保存在 controller 中，由 controller 直接进行 Kafka 集群管理。这样做的好处有以下几个：Kafka 不再依赖外部框架，而是能够独立运行；

每个消费者都会和coordinator保持心跳（默认3s），一旦超时（session.timeout.ms=45s），该消费者会被移除，并触发再平衡；或者消费者处理消息的时间过长（max.poll.interval.ms5分钟），也会触发再平衡。coordinator节点选择 = groupid的hashcode值 % 50（ __consumer_offsets的分区数量）Coordinator就把消费方案下发给各个consumer。把消费方案发给coordinator。leader会负责制定消费方案。

通过ls命令可以查看kafka相关信息Zookeeper中存储的Kafka信息。

在以前遇到kafka消费组死掉，一直没去确认kafka什么情况下会导致消费组死掉，因为直接看源码，看待调用的地方比较多，好几次都想直接修改源码，但是因为要改动的比较多，怕以后不兼容，然后前几天学了字节码相关的，发现这个非常的好用。【kafka】kafka 查看 GroupCoordinator 和 ConsumerCoordinator【kafka】消费组 死掉 kafka Marking the coordinator dead for group。

一个环境，kafka正常，名称叫topic_lcc,然后这个topic在三个地方使用然后这个消费组报错信息如下对应的代码如下xxx后来无论是创建单个分区的topic、还是共用一个消费组，都不能复现这个问题。

在做flink任务的时候，报错 详细错误如下在SourceCoordinator中我们调用了start方法启动.启动方法主要做了2件事创建代码如下source.createEnumerator,这里创建仅仅是赋值没啥重要的2.启动Enumerator启动Enumerator方法中也是主要做了3件事2.1 构建kafka客户端构建kafka客户端主要调用了kafka的方法2.2 发现分区发现分区的逻辑如下2.2.1 getPartitionChanges这里我们主要看看getPartiti