九师兄

Producer 消息重复和消息丢失的原因，主要就是kafka 为了提高数据可靠性所提供的重试机制，如果禁用重试机制，那么一旦数据发送失败，数据就丢失了。而数据重复，恰恰是因为开启重试机制后，如果因为网络阻塞或不稳定，导致数据重新发送。那么数据就有可能是重复的。所以kalka 提供了幂等性操作解决数据重复，并且幂等性操作要求必须开启重试功能和 ACK 取值为-1，这样，数据就不会丢失了。

Kafka 存储方式为顺序读写，机械硬盘的最大分势在于随机读写慢。所以使用机械硬盘并不会造成性能低下。所以磁盘选用普通机械硬盘即可，Kafka 自身已经有冗余机制，而旦通过分区的设计，实现了负载均衡的功能。不做磁盘组raid 阵列也是可以的。磁盘空间需要多少，需要根据具体场景进行简单估算设计场景：日志数据每天向katka 发送 1亿条数据，每条数据有两个副本防止数据丢失，数据保存两周，每条消息平均大小为 1KB。katka 除了消息数据还有其他类型的数据，故增加10%的冗余空间，则需要两周时间则为。

本章是对上一章的补充说明。消费者想要拉取主题分区的数据，首先必须要加入到一个组中。但是一个组中有多个消费者的话，那么每一个消费者该如何消费呢，是不是像图中一样的消费策略呢？如果是的话，那假设消费者组中只有2个消费者或有 4个消费者，和分区的数量不匹配，怎么办？所以这里，我们需要给大家介绍一下，Kafka 中基，Kafka中基本的消费者组中的消费者和分区之间的分配规则：同一个消费者组的消费者都订阅同一个主题，所以消费者组中的多个消费者可以共同消费一个主题中的所有数据。

表中的后5个值为动态值，需要根据数据时中key，valve 变化计算得到。此处以数据 key=keyl, value=valuel 为例。假设我们只发送一条数据，然后key和vale如图，那么只会占用17个字节，然后加上61个字节为78个字节，然后我们去看看日志文件。，如下图我们查看日志可以发现有批次头和数据信息。批次头的总大小为61 byte。发现日志文件正好是78个字节。批次头包含了很多信息。

UnifiedLog中包含了多个LogSegment，然后里面有个跳跃表，存储格式如下，LogSegment的起始位置和对应的LogSegment。现在我们找到了文件段后，但是我们的LogSegment文件段包含了3个文件，然后我们要找到具体的位置，需要使用索引文件。kafka数据存储有3个基础文件，分别是时间稀疏索引文件，offset稀疏索引文件，日志文件。这里找到位置之后，拿到的数据，不仅仅是索引位置的数据，索引之后的数据也会拿到。可以看到我们的数据中是有偏移量信息的，0/4/8之类的。

本章我们通过改动源码的方式来看看事务执行的流程。我们首先在发送请求的地方增加如下日志然后增加事务log日志然后为了能利用上我们的源码，我们将测试类拷贝到源码里面然后我们启动源码的kafka服务器，然后再启动生产者，那么两端都打印了日志信息。然后把两端的日志都拷贝出来，然后根据时间融合一下。融合后的结果如下缩进的是服务器打印的信息。可以看到在初始化事务之前打印了很多信息，这个只有2种请求类型，FIND_COORDINATOR寻找COORDINATOR，INIT_PRODUCER_ID。

Kafka 分区器（Partitioner）用于确定消息在 Kafka 主题中的分区（Partition）分配方式。当生产者发送消息到 Kafka 主题时，分区器决定将消息发送到哪个分区中。分区器的主要作用包括：负载均衡：通过合理的分区策略，分区器可以确保消息在各个分区之间均匀分布，从而实现负载均衡。这样可以避免某些分区的负载过重，提高整个 Kafka 集群的性能和可靠性。顺序保证：在某些情况下，需要保证特定键（Key）或者特定的消息具有顺序性。

flink kafka source在有ck的情况下，从上一次ck或者savepoint启动时，要是ck中的kafka offset不在当前kafka topic的offset范围内，就是出现了越界，flink kafka source会如何处理？这个情况 ck找不到消费位置的时候，会根据你的消费kafka的配置,如果你配置的是 auto.reset.offset=earliest 那么会从你的topic当前的最早位置消费，如果配置的是latest 那么就是最新位置消费。

20240126日，今天遇到一个kafka环境报错：IOException: No space left on device。此时修改保留时间已经无效了，因为你需要先重启kafka，但是现在无法重启，因此只能清楚topic数据，然后重启。怀疑是kafka日志太多和flink yarn 日志太多。然后查看磁盘总量信息已经不足了。

异常栈信息如下主要看方法addPartition方法。错误消息 “Unexpected existing replica assignment for topic ‘$topic’, partition id 0 is missing” 意味着在尝试扩展 Kafka 主题时出现了一个问题。这通常涉及到分区的副本分配或者 ZooKeeper 中的配置。让我们来逐步分析和解决这个问题：1.检查主题配置：2.确保你正在尝试扩展的主题存在，并且已经正确地创建。

文章讨论了在使用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冲突。