touch_reach_task_主题下Kafka元数据拉取失败

Question

在 `touch_reach_task_` 主题下，Kafka 元数据拉取失败的典型问题是：消费者启动时反复抛出 `UnknownTopicOrPartitionException` 或 `LeaderNotAvailableException`，日志显示 `Failed to find leader for [touch_reach_task_, 0]`。根本原因常为：该主题虽已创建，但分区 Leader 尚未完成选举（如 Kafka 集群刚重启、Broker 间元数据同步延迟）；或主题配置了 `auto.create.topics.enable=false`，而生产者未预先创建主题，导致消费者首次请求元数据时 Broker 返回空 Leader 信息；此外，若 `client.id` 或 `group.id` 配置异常，也可能触发元数据缓存污染，使客户端持续使用过期元数据。该问题表现为消费停滞、Offset 提交失败、重平衡频繁，且不伴随明显网络错误，易被误判为代码逻辑缺陷。

Answer 1

```html

一、现象层：典型日志与表征行为

• 消费者启动后持续输出：Failed to find leader for [touch_reach_task_, 0]
• 伴随异常：UnknownTopicOrPartitionException（主题/分区不存在）或 LeaderNotAvailableException（Leader未就绪）
• Offset 提交失败（CommitFailedException），KafkaConsumer#commitSync() 抛出超时或不可重试异常
• 消费者组频繁触发 Rebalance（REBALANCING → STABLE → REBALANCING 循环）
• 无网络层报错（如 Connection refused、TimeoutException），tcpdump 显示 TCP 握手与请求正常

二、机制层：Kafka 元数据生命周期与缓存模型

Kafka 客户端元数据管理遵循「懒加载 + 异步刷新 + 本地缓存」三阶段模型：

1. 首次请求：消费者向任意 Broker 发送 MetadataRequest 获取 touch_reach_task_ 的分区拓扑与 Leader 信息
2. Broker 响应：若 Leader 尚未选举完成（zk /brokers/topics/touch_reach_task_/partitions/0/state 中 "leader":-1），则返回空 Leader；若主题根本不存在且 auto.create.topics.enable=false，则返回 UNKNOWN_TOPIC_OR_PARTITION
3. 客户端缓存：MetadataCache 将该响应持久化为「已知但不可用」状态，后续请求在 metadata.max.age.ms（默认 5m）内复用该缓存，不主动刷新
4. 污染放大：当 client.id=prod-1 被多个实例复用，或 group.id=reach-consumer-v1 在不同环境混用，会导致元数据缓存跨上下文污染

三、根因层：三大核心故障路径分析

根因类型	触发条件	验证命令	关键指标
Leader 选举延迟	Kafka 集群重启后 30s 内消费者启动	kafka-topics.sh --bootstrap-server x:9092 --describe --topic touch_reach_task_	Output 含 Leader: none 或 Leader: -1
主题未预创建	auto.create.topics.enable=false 且生产者从未写入	kafka-topics.sh --list | grep touch_reach_task_	返回空，或 Describe 报 Topic 'touch_reach_task_' does not exist
元数据缓存污染	group.id 在测试/生产环境共用；或 client.id 硬编码为固定值	kafka-consumer-groups.sh --bootstrap-server x:9092 --group reach-consumer-v1 --describe	显示 UNKNOWN 成员状态，或 OFFSET 列全为 -

四、诊断层：标准化排查流程图

graph TD
  A[消费者报 Failed to find leader for [touch_reach_task_, 0]] --> B{主题是否存在？}
  B -->|否| C[执行 kafka-topics.sh --list 验证]
  B -->|是| D{Leader 是否就绪？}
  C --> E[创建主题：--replication-factor 3 --partitions 6]
  D -->|否| F[等待 60s 后重试 describe]
  D -->|是| G{client.id/group.id 是否唯一？}
  F --> H[检查 zk /controller_epoch & /brokers/ids]
  G -->|否| I[重构 client.id = ${HOSTNAME}-${PID}, group.id = env-app-version]
  G -->|是| J[检查 metadata.max.age.ms 是否过长]

五、解决层：生产级修复方案

• 预防性措施：CI/CD 流水线中集成 kafka-topics.sh --create 步骤，主题定义纳入 GitOps 管控（如 Terraform Kafka Provider）
• 启动时防御：消费者启动前执行元数据探活逻辑：

  try {
    consumer.listTopics().get(10, TimeUnit.SECONDS).keySet().contains("touch_reach_task_");
    // 再检查分区 Leader
    final TopicPartition tp = new TopicPartition("touch_reach_task_", 0);
    final List<PartitionInfo> infos = consumer.partitionsFor("touch_reach_task_");
    if (infos.stream().noneMatch(p -> p.partition() == 0 && p.leader() != null)) {
      throw new IllegalStateException("Leader not ready for touch_reach_task_ partition 0");
    }
  } catch (TimeoutException e) {
    // 重试或告警
  }

• 运行时治理：启用 metadata.max.age.ms=30000（30s），配合 reconnect.backoff.ms=1000 缩短元数据陈旧窗口
• 监控增强：Prometheus 指标 kafka_consumer_metadata_age_seconds{topic=~"touch_reach_task_.*"} > 30s 时触发告警

```