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

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

文章目录

  • [Kafka常见问题之Kafka 报错:org.apache.kafka.common.errors.NotLeaderOrFollowerException](#Kafka常见问题之Kafka 报错:org.apache.kafka.common.errors.NotLeaderOrFollowerException)
  • [0. NotLeaderOrFollowerException描述](#0. NotLeaderOrFollowerException描述)
  • [1. NotLeaderOrFollowerException产生背景](#1. NotLeaderOrFollowerException产生背景)
  • [2. NotLeaderOrFollowerException产生原因](#2. NotLeaderOrFollowerException产生原因)
    • [2.1 分区的 Leader 不可用](#2.1 分区的 Leader 不可用)
    • [2.2 元数据过时](#2.2 元数据过时)
    • [2.3 分区未分配 Leader](#2.3 分区未分配 Leader)
    • [2.4 Broker 配置错误](#2.4 Broker 配置错误)
    • [2.5 重平衡导致的临时不可用](#2.5 重平衡导致的临时不可用)
  • [3. 排查方向](#3. 排查方向)
    • [3.1 检查 Kafka Broker 状态](#3.1 检查 Kafka Broker 状态)
    • [3.2 查看分区的 Leader 状态](#3.2 查看分区的 Leader 状态)
    • [3.3 手动触发分区重新分配](#3.3 手动触发分区重新分配)
    • [3.4 检查客户端的元数据刷新](#3.4 检查客户端的元数据刷新)
    • [3.5 检查副本同步配置](#3.5 检查副本同步配置)
    • [3.6 避免频繁的分区重平衡](#3.6 避免频繁的分区重平衡)
  • [4. 具体案例](#4. 具体案例)
    • [案例 1:生产者发送消息失败](#案例 1:生产者发送消息失败)
    • [案例 2:消费者拉取消息失败](#案例 2:消费者拉取消息失败)

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 是否都处于正常运行状态。可以通过以下命令检查:

bash 复制代码
bin/kafka-broker-api-versions.sh --bootstrap-server <broker_host>:9092

3.2 查看分区的 Leader 状态

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

bash 复制代码
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 信息异常,可以尝试重新分配分区。

生成分配计划

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

执行分配计划

bash 复制代码
bin/kafka-reassign-partitions.sh --bootstrap-server <broker_host>:9092 --execute --reassignment-json-file reassignment.json

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

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

  • 修改生产者配置:

    properties 复制代码
    metadata.max.age.ms=30000  # 每 30 秒刷新元数据
  • 修改消费者配置:

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

3.5 检查副本同步配置

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

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

    properties 复制代码
    replica.lag.time.max.ms=10000    # 副本允许的最大同步延迟时间
    replica.lag.max.messages=4000   # 副本允许的最大同步消息数量
  • 增加分区副本数,提高副本的容错能力。

3.6 避免频繁的分区重平衡

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

properties 复制代码
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 信息:

    bash 复制代码
    bin/kafka-topics.sh --bootstrap-server <broker_host>:9092 --describe --topic my_topic
  2. 如果 Leader-1,触发分区的 Leader 重新选举:

    bash 复制代码
    bin/kafka-preferred-replica-election.sh --bootstrap-server <broker_host>:9092

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

现象

消费者从 Kafka 主题消费消息时,报错:

复制代码
org.apache.kafka.common.errors.NotLeaderOrFollowerException

原因

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

解决方法

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

    properties 复制代码
    metadata.max.age.ms=30000  # 每 30 秒刷新元数据
  2. 查看 Kafka 分区状态,确保分区有 Leader:

    bash 复制代码
    bin/kafka-topics.sh --bootstrap-server <broker_host>:9092 --describe --topic my_topic
相关推荐
沉着的码农1 小时前
【设计模式】基于责任链模式的参数校验
java·spring boot·分布式
ZHOU_WUYI13 小时前
一个简单的分布式追踪系统
分布式
码不停蹄的玄黓17 小时前
MySQL分布式ID冲突详解:场景、原因与解决方案
数据库·分布式·mysql·id冲突
王小王-12317 小时前
基于Hadoop的公共自行车数据分布式存储和计算平台的设计与实现
大数据·hive·hadoop·分布式·hadoop公共自行车·共享单车大数据分析·hadoop共享单车
要开心吖ZSH19 小时前
《Spring 中上下文传递的那些事儿》Part 4:分布式链路追踪 —— Sleuth + Zipkin 实践
java·分布式·spring
幼稚园的山代王20 小时前
RabbitMQ 4.1.1初体验
分布式·rabbitmq·ruby
百锦再20 小时前
RabbitMQ用法的6种核心模式全面解析
分布式·rabbitmq·路由·消息·通道·交换机·代理
一路向北North20 小时前
RabbitMQ简单消息监听和确认
分布式·rabbitmq·ruby
真实的菜20 小时前
Kafka生态整合深度解析:构建现代化数据架构的核心枢纽
架构·kafka·linq
一路向北North1 天前
使用reactor-rabbitmq库监听Rabbitmq
分布式·rabbitmq·ruby