kafka-2.1

 

[2025-11-04 08:01:28,169] DEBUG [Controller id=0] Topics not in preferred replica for broker 0 Map() (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] TRACE [Controller id=0] Leader imbalance ratio for broker 0 is 0.0 (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] DEBUG [Controller id=0] Topics not in preferred replica for broker 1 Map(newurlkill-27 -> Vector(1, 3, 4), __consumer_offsets-38 -> Vector(1, 2, 3), cong_test-24 -> Vector(1, 2), __consumer_offsets-8 -> Vector(1, 4, 0), __consumer_offsets-13 -> Vector(1, 0, 2), newurlkill-2 -> Vector(1, 2, 3), mobilekill-27 -> Vector(1, 3, 4), mobilekill_old-1 -> Vector(1, 2, 3), __consumer_offsets-43 -> Vector(1, 3, 4), cong_test-29 -> Vector(1, 3), mobilekill-2 -> Vector(1, 2, 3), __consumer_offsets-48 -> Vector(1, 4, 0), __consumer_offsets-18 -> Vector(1, 2, 3), newurlkill-7 -> Vector(1, 3, 4), cong_test-4 -> Vector(1, 2), cong_test-9 -> Vector(1, 3), __consumer_offsets-23 -> Vector(1, 3, 4), newurlkill-12 -> Vector(1, 4, 0), mobilekill-7 -> Vector(1, 3, 4), boot_speed_ent-0 -> Vector(1, 2, 3), mobilekill-12 -> Vector(1, 4, 0), cong_test-14 -> Vector(1, 4), newurlkill-17 -> Vector(1, 0, 2), __consumer_offsets-28 -> Vector(1, 4, 0), ycs_bd-1 -> Vector(1, 2, 3), __consumer_offsets-3 -> Vector(1, 3, 4), ycs_bd_ent-4 -> Vector(1, 4, 0), mobilekill-17 -> Vector(1, 0, 2), __consumer_offsets-33 -> Vector(1, 0, 2), mobilekill-22 -> Vector(1, 2, 3), newurlkill-22 -> Vector(1, 2, 3), cong_test-19 -> Vector(1, 0)) (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] TRACE [Controller id=0] Leader imbalance ratio for broker 1 is 1.0 (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] DEBUG [Controller id=0] Topics not in preferred replica for broker 2 Map(cong_test-15 -> Vector(2, 1)) (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] TRACE [Controller id=0] Leader imbalance ratio for broker 2 is 0.03125 (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] DEBUG [Controller id=0] Topics not in preferred replica for broker 3 Map() (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] TRACE [Controller id=0] Leader imbalance ratio for broker 3 is 0.0 (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] DEBUG [Controller id=0] Topics not in preferred replica for broker 4 Map() (kafka.controller.KafkaController)
[2025-11-04 08:01:28,169] TRACE [Controller id=0] Leader imbalance ratio for broker 4 is 0.0 (kafka.controller.KafkaController)
[2025-11-04 08:04:28,169] TRACE [Controller id=0] Checking need to trigger auto leader balancing (kafka.controller.KafkaController)

🧭 Kafka 三层架构完整文档（2025-11-04）

一、总体架构图（逻辑层 ⇄ 系统层 ⇄ 客户端层）

             ┌──────────────────────────┐
             │  客户端层（Producer / Consumer）     │
             │ ──────────────────────────────── │
             │ Producer → 发送消息 (acks, batch) │
             │ Consumer ← 拉取消息 (poll, commit) │
             │ GroupCoordinator ↔ 消费组管理       │
             │ GroupMetadataManager ↔ 元数据管理   │
             │ __consumer_offsets ↔ 消费者偏移存储 │
             └──────────────────────────┘
                           │
             ╔═════════════╧═════════════╗
             ▼                           ▼
   ┌──────────────────────────┐  ┌──────────────────────────┐
   │ 系统层（Broker 集群 & Controller） │  │ 逻辑层（Topic / Partition） │
   │ ───────────────────────────── │  │ ───────────────────────────── │
   │ Controller：集群控制、Leader选举       │  │ Topic → Partition → Offset   │
   │ Broker：消息存储、复制、日志管理      │  │ Record 顺序写入 LogSegment   │
   │ ISR：同步副本集合                   │  │ Replica 保证顺序和一致性      │
   │ ReplicaFetcher：副本同步线程         │  │                              │
   │ LogManager：日志段管理与恢复          │  │                              │
   │ ReplicaAlterLogDirsManager：迁移分区日志│ │                              │
   │ TransactionCoordinator：事务管理       │ │                              │
   │ QuotasManager：吞吐限额控制           │ │                              │
   │ ControllerChannelManager：控制消息传输 │ │                              │
   │ ZooKeeper / KRaft：元数据存储与管理   │ │                              │
   └──────────────────────────┘  └──────────────────────────┘
             ▲                           ▲
             ╚═════════════ 数据流 ═════════════╝

二、三层核心组件及职责解释

1️⃣ 逻辑层（消息模型层）

核心组件职责说明
Topic 消息逻辑集合单位，用于区分不同类型或主题的消息
Partition Topic 的物理划分，支持并行存储与消费
Offset 分区内消息的唯一顺序标识，用于消费进度定位
Replica 分区的副本，用于保证容错和一致性
LogSegment 分区日志段文件，顺序存储消息，支持滚动和清理

2️⃣ 系统层（集群运行层）

核心组件职责说明
Broker Kafka 节点，负责存储消息、处理请求、执行副本同步
Controller 集群控制节点，负责 Leader 选举、分区分配和副本管理
ISR (In-Sync Replica) 与 Leader 同步的副本集合，确保数据一致性
ReplicaFetcher Broker 中用于拉取 Leader 数据的线程，保证副本同步
LogManager 管理分区日志文件（LogSegment），支持日志滚动与恢复
ReplicaAlterLogDirsManager 支持分区日志迁移或变更存储目录
TransactionCoordinator 管理幂等生产和事务消息，保证 Exactly Once 语义
QuotasManager 限制生产者/消费者吞吐，防止过载
ControllerChannelManager 控制 Broker 之间和 Controller 的内部消息通信
ZooKeeper / KRaft 元数据管理和集群协调（选举、偏移存储、事务元数据等）

3️⃣ 客户端层（生产与消费层）

核心组件职责说明
Producer 发送消息到 Broker，可配置 acks、batch、linger 等参数
Consumer 拉取 Broker 消息，处理业务逻辑，并提交 offset
GroupCoordinator 管理消费组成员、分配分区、处理 rebalance
GroupMetadataManager 管理消费组元数据，持久化成员信息与 offset
__consumer_offsets 内部主题，用于存储消费者提交的偏移量

三、交互机制与触发事件

交互路径发起方接收方功能说明典型日志常见问题
Producer → Broker Producer Broker Leader 发送消息并请求确认（acks） [Producer] acks=1 request complete 延迟高、消息丢失、batch.size 过大
Broker Leader → Follower Broker ReplicaFetcher 副本同步 [ReplicaFetcher] Error sending fetch request 网络断开、Follower lag、ISR 收缩
Controller → Broker Controller Broker 分区 leader 选举与 ISR 调整 [Controller id=3] New leader for partition Controller 频繁抖动、分区迁移
Consumer → Broker Consumer Leader 拉取消息 [Consumer clientId=...] Fetched records 消费延迟、流控限速
Consumer → GroupCoordinator Consumer GroupCoordinator rebalance、offset commit [GroupCoordinator] Group rebalanced Rebalance 频繁、commit timeout
Broker → __consumer_offsets Broker LogSegment 消费者 offset 提交 [LogCleaner] Cleaning log __consumer_offsets-xx 延迟提交、compact 延迟可见

四、实战日志案例分析

日志示例：

[2025-11-04 09:38:42,723] INFO [ReplicaFetcher replicaId=0, leaderId=3, fetcherId=6] 
Error sending fetch request ... Connection to 3 was disconnected before the response was read

分析：

  • 所属层：系统层（ReplicaFetcher）

  • 可能原因：

    • Leader Broker I/O 异常或 GC 暂停

    • 网络断开或延迟高

    • Follower lag 或 ISR 收缩

诊断路径：

  1. 检查 Broker 节点负载、磁盘和 GC 日志

  2. 检查网络链路和防火墙

  3. 查看 ISR 收缩次数 (isrShrinkRate)

优化建议：

  • 提高 num.replica.fetchers

  • 调整 replica.lag.time.max.ms

  • 稳定 Controller，避免频繁选举

  • 优化磁盘 I/O 和 Broker GC 配置

五、三层故障闭环诊断路径

客户端感知 → 系统层分析 → 逻辑层回溯

  • 客户端层：异常消费、重复消费、Rebalance 频繁 → 查看 __consumer_offsets、GroupMetadataManager

  • 系统层：ReplicaFetcher I/O、Controller 选举、ISR 收缩 → 检查 Broker、LogManager、ReplicaAlterLogDirsManager

  • 逻辑层：Partition 分布倾斜、LogSegment 损坏 → 检查 Partition 分布、日志文件完整性

六、性能与可靠性优化方向

层次优化目标核心参数建议配置方向
逻辑层 日志管理、数据均衡 log.segment.bytes, log.retention.ms, log.cleanup.policy 合理分段（1~2GB），定期清理 compact topics，均衡 Partition 分布
系统层 副本同步稳定、快速恢复 replica.lag.time.max.ms, num.replica.fetchers, unclean.leader.election.enable 提高 fetcher 数量，禁用 unclean 选举，稳定 Controller
客户端层 提升吞吐、降低 Rebalance linger.ms, batch.size, max.poll.interval.ms, heartbeat.interval.ms Producer 增大 batch/linger，Consumer 调整心跳和 poll 间隔，使用 Sticky Assignor

七、三层架构图总结（问题与优化）

┌────────────────────────────────────────────┐
│ 客户端层（Producer / Consumer）             │
│ 延迟高 → 调 batch/linger                     │
│ Rebalance → 心跳/poll 参数调整               │
│ Offset commit 异常 → GroupMetadataManager / Coordinator 问题 │
│────────────────────────────────────────────│
│ 系统层（Broker / Controller）               │
│ ReplicaFetcher 断开 → 网络/GC/磁盘           │
│ Controller 频繁选举 → Broker 不稳定         │
│ ISR 收缩 → 副本落后/延迟高                  │
│ LogManager/ReplicaAlterLogDirsManager 问题  │
│────────────────────────────────────────────│
│ 逻辑层（Topic / Partition）                 │
│ Offset 丢失 → commit 不一致                  │
│ 分区倾斜 → 热点/并发瓶颈                   │
│ LogSegment 损坏 → 存储/磁盘异常            │
└────────────────────────────────────────────┘

八、一句话总结三层架构逻辑

层次核心命题
逻辑层 定义消息在 Kafka 世界中的“存在形式”
系统层 确保 Kafka 世界的“稳定与容错”
客户端层 决定 Kafka 世界的“使用方式与性能语义”

✅ 特点：

  • 保留所有原有核心组件及职责

  • 补充 QuotasManager、ControllerChannelManager 等关键组件

  • 结合日志和故障案例进行分析

  • 可直接用于 SRE 日常运维、排障与性能调优

Kafka Controller，主要是 kafka.controller.KafkaController 输出的调试（DEBUG/TRACE）信息，涉及 Leader 分布、Leader imbalance、Preferred Replica。我帮你分析问题并给出诊断思路。

1️⃣ 日志内容拆解

核心字段与含义

日志片段含义
Topics not in preferred replica for broker X Map(...) 该 Broker 上的 Leader 分区不在其首选副本（Preferred Replica）上。Map 中 key 为 Topic-Partition，value 为副本列表。
Leader imbalance ratio for broker X is Y Leader 不均衡比率。0 表示该 Broker 上的 Leader 全部在首选副本，1.0 表示全部不在首选副本，越高说明 Leader 分布不均衡。
Checking need to trigger auto leader balancing Controller 正在检查是否需要触发自动 Leader rebalance。

日志特点

  1. Broker 0、3、4 的 Leader imbalance 比率为 0.0 → 分布均衡

  2. Broker 1 的 Leader imbalance 比率为 1.0 → 所有分区 Leader 都不在首选副本

  3. Broker 2 的 Leader imbalance 比率为 0.03125 → 轻微不均衡

  4. Controller 记录了大量 Topics not in preferred replica → Broker 1 问题最严重

2️⃣ 问题分析

  1. Broker 1 Leader 全部不在 Preferred Replica

    • 说明 Broker 1 上的分区 Leader 都被迁移到了其他 Broker，可能由于：

      • Broker 1 最近重启或下线，Leader 被迁移

      • Broker 1 负载过高，Controller 做了 Leader reassignment

      • auto.leader.rebalance.enable 或 leader.imbalance.check.interval.seconds 触发了自动平衡

  2. Broker 2 轻微不均衡

    • 只有少数 Topic-Partition 不在首选副本

    • 可通过自动 Leader balancing 修复

  3. Broker 0/3/4 正常

    • Leader 分布符合首选副本

  4. TRACE: Checking need to trigger auto leader balancing

    • Controller 在周期性检查是否需要平衡 Leader

    • 说明系统检测到不均衡，可能会触发 preferred replica leader election

3️⃣ 可能影响

  • 消费延迟：如果 Leader 不在首选副本且副本位于网络或磁盘慢的 Broker 上，Consumer 拉取可能延迟增加

  • 负载不均：Broker 1 没有 Leader，负载可能集中到其他 Broker

  • 故障恢复风险：如果 Broker 1 离线或有网络波动，分区 Leader 会频繁迁移 → ISR 收缩

4️⃣ 排查路径

4.1 查看 Broker 状态

# 查看 Broker 是否在线
bin/kafka-broker-api-versions.sh --bootstrap-server <broker1>:9092

# 查看 ISR 与 Leader 分布
bin/kafka-topics.sh --describe --bootstrap-server <broker1>:9092

重点查看：

  • 每个 Partition 的 Leader

  • ISR 是否完整

  • 是否有 Offline 或 Under-replicated Partition (URP)

4.2 查看 Controller 状态

bin/kafka-controller.sh --describe
# 或通过 JMX / metrics 查看 Controller 节点

  • 检查 Controller 是否稳定

  • 查看 LeaderImbalance、PreferredReplicaLeaderElection 指标

4.3 自动 Leader Rebalance

  • 如果 Broker 负载恢复且不均衡严重，可以手动触发：

bin/kafka-preferred-replica-election.sh --zookeeper <zk_connect>

注意：在 KRaft 模式下需使用对应 Admin API 触发。

4.4 网络与资源检查

  • Broker 1 最近是否有网络抖动 / 重启

  • 磁盘 I/O 是否正常

  • GC 暂停或 CPU 峰值

5️⃣ 优化建议

  1. 确保 Broker 稳定：避免频繁重启或网络抖动

  2. 开启自动 Leader Rebalance：

    • auto.leader.rebalance.enable=true

    • leader.imbalance.check.interval.seconds=300

  3. 监控 Leader imbalance 指标：

    • kafka.controller:type=KafkaController,name=LeaderImbalance

  4. 合理分区分布：

    • 避免单 Broker 集中过多 Leader

    • 使用 kafka-topics.sh --alter --partitions 平衡分区

🔹 总结

  • 日志显示 Broker 1 上 Leader 全部不在首选副本，导致 Leader imbalance = 1.0

  • 轻微不均衡在 Broker 2，其他 Broker 正常

  • Controller 正在周期性检测是否触发自动 Leader rebalance

  • 建议：检查 Broker 1 状态、ISR、网络与磁盘，并可手动或自动触发 Preferred Replica Leader Election

 

posted on 2025-11-04 10:01  吃草的青蛙  阅读(9)  评论(0)    收藏  举报

导航