notleaderforpartitionexception表示客户端请求发送到了非leader副本的broker，可能由leader自动重选举、元数据缓存过期、消费者组重平衡、isr同步滞后或broker资源瓶颈引发。
如果您在Kafka客户端日志中观察到 NotLeaderForPartitionException 异常，该现象可能与分区迁移相关，但并不必然表示当前正在执行主动的分区迁移操作。该异常本质反映的是客户端请求所发送的目标Broker节点并非该分区当前的Leader副本。以下是多种可能触发此异常的具体情形：
一、Leader节点发生自动重选举
当某个分区的Leader Broker因宕机、网络隔离、GC停顿过长或手动下线而不可用时，Kafka控制器会触发Leader重选举，从ISR（In-Sync Replicas）列表中选出新Leader。在此切换过程中，客户端缓存的旧Leader元数据尚未更新，仍向原地址发起请求，从而抛出该异常。
1、使用 kafka-topics.sh --describe 命令检查目标topic-partition的当前Leader ID及ISR列表；
2、比对输出中的 Leader 字段与客户端连接的Broker ID是否一致；
3、若不一致，说明Leader已变更，需等待客户端元数据刷新或手动触发刷新。
二、客户端元数据缓存未及时更新
Kafka客户端（Producer/Consumer）本地维护一份分区元数据缓存，包含各分区Leader所在的Broker地址。该缓存默认每隔 metadata.max.age.ms（默认300000毫秒，即5分钟）主动拉取一次最新元数据。若Leader在两次刷新之间发生变更，客户端将持续向失效地址发送请求，直至下次刷新完成。
1、在生产者配置中显式设置 metadata.max.age.ms=60000 以缩短元数据陈旧窗口；
2、在消费者配置中添加 metadata.max.age.ms=30000 并配合 reconnect.backoff.ms=1000 提升恢复响应速度；
3、调用 producer.partitionsFor(topic) 或 consumer.listTopics() 可强制触发一次元数据同步。
三、消费者组重平衡期间临时性错连
当消费者组内成员数量变化（如实例启停）、订阅主题变更或分区数调整时，Kafka将触发Rebalance流程，重新分配分区所有权。在此过程中，部分消费者可能短暂持有已失效的分区分配，并尝试向原Leader发送fetch请求，导致异常出现。该现象通常持续数秒至数十秒，属正常过渡行为。
1、通过 kafka-consumer-groups.sh --describe 查看消费者组当前状态及各成员分配的分区；
2、确认是否存在 REBALANCING 状态或频繁的 ASSIGNMENT 日志；
3、检查消费者配置中 session.timeout.ms 和 heartbeat.interval.ms 是否设置合理，避免因心跳超时误判为离线而触发非必要重平衡。
四、ISR副本同步滞后导致Leader被强制切换
若某Follower副本因磁盘IO瓶颈、网络延迟或负载过高长期无法追上Leader日志偏移量，将被控制器移出ISR列表。当ISR仅剩一个副本时，该副本即为Leader；一旦其也发生故障，系统可能无法选出新Leader，或在极短时间内完成切换，造成客户端感知到Leader“瞬时丢失”。
1、执行 kafka-topics.sh --describe --under-replicated-partitions 检查是否存在未同步分区；
2、查看Broker日志中是否高频出现 Failed to update leader cache 或 ISR shrinkage 相关条目；
3、监控指标 UnderReplicatedPartitions 和 OfflinePartitionsCount 是否持续非零。
五、Broker端存在资源瓶颈或JVM异常
单个Broker若遭遇长时间Full GC、CPU打满、磁盘写满或文件描述符耗尽，可能导致其虽存活但无法响应元数据请求或处理分区读写，控制器判定其失联后触发Leader迁移。此时客户端仍可能缓存其旧地址并持续重试，引发批量异常。
1、检查对应Broker进程的GC日志，确认是否存在单次GC耗时超过 session.timeout.ms 的情况；
2、运行 df -h 和 lsof -n -p [broker_pid] | wc -l 验证磁盘空间与句柄数是否充足；
3、通过 top -H -p [broker_pid] 观察线程级CPU占用，识别是否存在阻塞或死循环线程。
