Kafka常见问题之Kafka 报错：org.apache.kafka.common.errors.NotLeaderOrFollowerException

NotLeaderOrFollowerException 是 Kafka 中常见的分区 Leader 问题，通常由 Broker 宕机、网络问题或分区元数据不同步引起。通过检查集群状态、合理配置副本同步机制、调整客户端参数以及监控集群，可以有效减少此类问题的发生，提高 Kafka 集群的稳定性和可靠性。

0. NotLeaderOrFollowerException描述

该错误表明客户端（生产者或消费者）向 Kafka Broker 发送请求时，目标分区的 Leader 不可用，或该 Broker 既不是分区的 Leader 也不是其副本（Follower）。因此，该 Broker 无法处理与该分区相关的请求。

1. NotLeaderOrFollowerException产生背景

该错误通常出现在以下场景：

• 生产者向分区 Leader 发送数据时：生产者通过元数据获取分区的 Leader 信息，如果 Leader 信息过时或不可用，生产者可能会向非 Leader 节点发送数据，导致该错误。
• 消费者从分区拉取数据时：消费者尝试从分区 Leader 拉取消息，如果 Leader 不可用或元数据不同步，则会出现该错误。
• Kafka 分区的 Leader 发生变更：当 Kafka 发生分区重平衡（Rebalance）或 Leader 重新选举时，客户端可能遇到临时的 Leader 不可用。

2. NotLeaderOrFollowerException产生原因

2.1 分区的 Leader 不可用

• Kafka 分区的 Leader 可能由于 Broker 宕机或网络问题变得不可用。
• 如果 Kafka 集群中的 ISR（同步副本集合）为空，可能无法选出新的 Leader。

2.2 元数据过时

• 客户端缓存的分区元数据已过期，但未及时刷新，导致请求被发送到错误的 Broker。

2.3 分区未分配 Leader

• 某些分区可能由于分区副本分配不均或配置问题，未正确分配 Leader。

2.4 Broker 配置错误

• Kafka Broker 的配置不正确，例如副本同步超时过短、分区分配不均等问题。

2.5 重平衡导致的临时不可用

• 消费者或生产者触发分区的重平衡时，短时间内可能导致分区的 Leader 信息不可用。

3. 排查方向

3.1 检查 Kafka Broker 状态

确认 Kafka 集群中的所有 Broker 是否都处于正常运行状态。可以通过以下命令检查：

bin/kafka-broker-api-versions.sh --bootstrap-server <broker_host>:9092

3.2 查看分区的 Leader 状态

通过以下命令检查目标分区的 Leader 信息是否正常：

bin/kafka-topics.sh --bootstrap-server <broker_host>:9092 --describe --topic <your_topic>

输出示例：

    Topic: my_topic    PartitionCount: 3    ReplicationFactor: 2    Configs:
    Topic: my_topic    Partition: 0    Leader: 1    Replicas: 1,2    Isr: 1,2
    Topic: my_topic    Partition: 1    Leader: 2    Replicas: 2,3    Isr: 2,3
    Topic: my_topic    Partition: 2    Leader: 3    Replicas: 3,1    Isr: 3,1

• 如果 Leader 为 -1，表示该分区没有 Leader，需要手动触发重新选举。

3.3 手动触发分区重新分配

如果某些分区的 Leader 信息异常，可以尝试重新分配分区。

生成分配计划：

bin/kafka-reassign-partitions.sh --bootstrap-server <broker_host>:9092 --generate --topics-to-move-json-file topics.json --broker-list "0,1,2"

执行分配计划：

bin/kafka-reassign-partitions.sh --bootstrap-server <broker_host>:9092 --execute --reassignment-json-file reassignment.json

3.4 检查客户端的元数据刷新

确保生产者和消费者的元数据刷新配置合理，避免使用过时的分区元数据。

• 修改生产者配置：

  metadata.max.age.ms=30000  # 每 30 秒刷新元数据
  

• 修改消费者配置：

  session.timeout.ms=10000  # 会话超时时间为 10 秒
  heartbeat.interval.ms=3000  # 心跳间隔为 3 秒
  

3.5 检查副本同步配置

确保副本的同步配置合理，以减少分区 Leader 不可用的风险：

• 增大以下 Broker 配置参数的值：

  replica.lag.time.max.ms=10000    # 副本允许的最大同步延迟时间
  replica.lag.max.messages=4000   # 副本允许的最大同步消息数量
  

• 增加分区副本数，提高副本的容错能力。

3.6 避免频繁的分区重平衡

调整消费者的配置，减少分区重平衡的频率。例如：

max.poll.interval.ms=300000  # 增加拉取消息的最大时间间隔

4. 具体案例

案例 1：生产者发送消息失败

现象：
生产者向 Kafka 主题发送消息时，报错：

org.apache.kafka.common.errors.NotLeaderOrFollowerException: This server is not the leader for that topic-partition.

原因：
Kafka 分区的 Leader 因 Broker 宕机不可用。

解决方法：

1. 查看 Kafka 集群的分区 Leader 信息：

   bin/kafka-topics.sh --bootstrap-server <broker_host>:9092 --describe --topic my_topic
   

2. 如果 Leader 为 -1，触发分区的 Leader 重新选举：

   bin/kafka-preferred-replica-election.sh --bootstrap-server <broker_host>:9092
   

案例 2：消费者拉取消息失败

现象：
消费者从 Kafka 主题消费消息时，报错：

org.apache.kafka.common.errors.NotLeaderOrFollowerException

原因：
分区的 Leader 变更或元数据未及时刷新。

解决方法：

1. 检查消费者的配置，确保元数据刷新频率足够高：

   metadata.max.age.ms=30000  # 每 30 秒刷新元数据
   

2. 查看 Kafka 分区状态，确保分区有 Leader：

   bin/kafka-topics.sh --bootstrap-server <broker_host>:9092 --describe --topic my_topic