Strimzi Kafka集群Producer发布失败报NotEnoughReplicasException问题咨询

问题背景 #

在AWS EKS环境中基于Strimzi的examples/metrics/kafka-metrics.yaml部署了3节点Kafka集群，持久化存储为10G，Broker核心配置如下：

replicas: 3
...
offsets.topic.replication.factor: 3
transaction.state.log.replication.factor: 3
transaction.state.log.min.isr: 2
default.replication.factor: 3
min.insync.replicas: 2

当前单分区主题TEST_TOPIC无法接收生产者消息，Broker报错：

Error processing append operation on partition TEST-TOPIC-0 (kafka.server.ReplicaManager) [data-plane-kafka-request-handler-4]
org.apache.kafka.common.errors.NotEnoughReplicasException: The size of the current ISR Set(1) is insufficient to satisfy the min.isr requirement of 2 for partition TEST-TOPIC-0

1. 所有Broker在线但ISR集合仅为1的可能原因 #

• 副本同步延迟超限：Broker进程虽在线，但副本节点存在磁盘IO（如AWS EBS IOPS不足）、网络带宽或CPU资源瓶颈，导致副本无法跟上主副本的消息进度，超过replica.lag.time.max.ms阈值后被移出ISR。
• Pod网络通信异常：EKS集群的网络策略（如Calico）限制了Broker Pod之间的内部通信端口（默认9092），导致副本无法与主副本同步数据或发送心跳，被主副本判定为不可用，移出ISR。
• 分区副本分配异常：TEST_TOPIC的副本未正确分配到3个Broker节点（如Strimzi调度策略问题、节点资源不足导致副本Pod未正常同步），实际只有主副本处于可用状态。
• 主题级配置覆盖：创建TEST_TOPIC时手动指定了replication.factor=1，覆盖了Broker的default.replication.factor=3配置，导致仅存在1个副本，ISR自然只有1。

2. 集群状态能否自动恢复？若无，有无不影响客户端的恢复方式 #

• 自动恢复场景：如果是临时网络抖动、磁盘IO峰值等短暂问题，当副本追上主副本进度且心跳恢复正常后，会自动重新加入ISR，集群无需干预即可恢复。
• 无法自动恢复时的无侵入恢复方式：
  • 临时调整主题min.insync.replicas：不重启Broker和客户端的前提下，先降低主题最小同步副本数恢复生产能力，后续解决根本问题后再改回：

    kafka-topics.sh --alter --topic TEST-TOPIC --bootstrap-server <your-broker-bootstrap> --config min.insync.replicas=1
    

  • 重新分配分区副本：若副本分配异常，使用kafka-reassign-partitions.sh生成并执行分区重分配计划，后台迁移副本的过程对客户端完全透明：
    1. 生成重分配计划文件reassign.json：

       {"version":1,"partitions":[{"topic":"TEST_TOPIC","partition":0,"replicas":[0,1,2]}]}
       

    2. 执行重分配：

       kafka-reassign-partitions.sh --bootstrap-server <your-broker-bootstrap> --reassignment-json-file reassign.json --execute
       

  • 调整副本同步阈值：临时增大replica.lag.time.max.ms（如改为60000），给滞后的副本足够时间追上主副本，待ISR恢复后调回原配置。

3. 核心系统确保生产者绝对能发送消息的推荐配置 #

Broker端配置

• 副本与同步副本匹配：保持replication.factor=3（对应3节点集群），min.insync.replicas=2，既保证数据一致性，又能容忍1个节点故障不影响生产。
• 优化复制参数：
  • 保留replica.lag.time.max.ms=30000（默认值，可根据业务延迟适当增大），避免正常延迟导致副本被移出ISR；
  • 设置replica.fetch.max.bytes=1048576（可根据消息大小调整）、replica.fetch.wait.max.ms=500，提升副本同步效率。
• 高性能存储：使用AWS EBS gp3（至少3000 IOPS）或io2存储类，避免磁盘IO成为瓶颈；Strimzi配置中指定storageClass为对应高性能存储类。
• 资源预留：给每个Broker Pod分配足够的CPU（如2核）和内存（如8G），优化JVM参数（如Xms=6G、Xmx=6G），避免GC频繁或资源不足影响复制线程。
• 网络保障：配置EKS网络策略允许Broker Pod之间的所有内部通信端口，确保副本同步和心跳正常。

生产者端配置

• 强一致性确认：设置acks=all，配合Broker的min.insync.replicas，确保消息被所有同步副本确认后才返回成功。
• 重试机制：设置retries=10、retry.backoff.ms=1000，遇到临时ISR不足、网络抖动等问题时自动重试；开启enable.idempotence=true，保证重试时消息不重复，实现Exactly-Once语义。
• 批量优化：合理设置linger.ms=5、batch.size=16384，在不影响业务延迟的前提下提高生产效率。

主题与运维配置

• 主题配置统一：确保所有业务主题继承Broker的replication.factor和min.insync.replicas配置，避免手动指定错误。
• 监控告警：通过Prometheus+Grafana监控Strimzi指标，重点关注kafka_replica_isr_count（ISR数量）、kafka_replica_lag（副本延迟），设置告警阈值，及时发现异常。
• 定期巡检：每周检查分区分配均匀性，避免单Broker负载过高；定期测试集群故障转移能力，确保节点故障时ISR能自动调整。

内容的提问来源于stack exchange，提问作者Mahendran