📚 课程目录第3章数据接入层运维

3、数据接入层运维：Kafka Topic管理、分区与副本策略、消息积压排查与处理

数据接入层，说白了就是实时推荐平台的「水龙头」。Kafka 要是出了问题，下游的 Flink、Spark Streaming 全得饿肚子。我见过太多团队在业务高峰期因为 Topic 配置不合理、分区数不够、副本策略没规划好，导致整个链路雪崩。今天咱们就把这块硬骨头啃下来。

3.1 Topic 管理：从创建到退役的全生命周期

Topic 是 Kafka 的逻辑容器。很多人觉得创建 Topic 就是敲一行命令的事，其实不然。我个人的习惯是，在创建之前先问三个问题：

这个 Topic 的预期吞吐量是多少？
数据保留多久？
消费者有多少个实例？

这三个问题直接决定了分区数和副本数。咱们先看创建命令：

# 创建一个名为 user-click 的 Topic，6 个分区，3 个副本
kafka-topics.sh --bootstrap-server kafka01:9092 \
  --create --topic user-click \
  --partitions 6 --replication-factor 3 \
  --config retention.ms=86400000 \
  --config min.insync.replicas=2

这里我特别强调一下 min.insync.replicas 这个参数。它控制的是「至少有多少个副本同步了数据，才算写入成功」。设成 2，意味着即使一个 broker 挂了，写入也不会丢数据。我在项目中遇到过因为设成 1，结果 broker 宕机导致数据丢失的惨案——嗯，从那以后我再也不敢偷懒了。

我的习惯：生产环境 Topic 的副本数至少 3，min.insync.replicas 至少 2。这样既能容忍单点故障，又不会因为副本同步太慢影响写入性能。

3.2 分区策略：吞吐量与顺序性的权衡

分区是 Kafka 并行度的基础。分区数越多，吞吐量越高，但也会带来一些副作用。你想想看，分区多了，文件句柄数、内存占用、Leader 选举时间都会增加。

那分区数到底设多少合适？我一般按这个公式估算：

分区数 = max(生产者吞吐量 / 单个分区写入能力, 消费者吞吐量 / 单个分区消费能力)

举个例子，假设你的生产者每秒要写入 100MB，单个分区能扛 20MB/s，那至少需要 5 个分区。消费者这边，如果每个消费者实例每秒能处理 10MB，你有 10 个实例，那 1 个分区就够了。取最大值，就是 5 个分区。

但这里有个坑——分区数一旦确定，后期扩容很麻烦。扩容后，已有的数据不会重新分布，新数据才会写入新分区。这就导致老分区压力大，新分区空闲。我建议一开始就留 30%-50% 的余量。

  关键点：分区数不是越多越好。超过 1000 个分区后，Kafka 的元数据管理、Leader 选举、Controller 负载都会显著上升。我个人建议单集群分区数控制在 2000 以内。

3.3 副本策略：数据安全与性能的平衡

副本的作用很简单——数据冗余。但副本怎么分布，很有讲究。Kafka 默认的副本分配策略是「轮询」，尽量把副本分散到不同的 broker 上。但如果你有机架信息，还可以开启机架感知。

看这张图，你就明白副本是怎么分布的：

副本策略的核心参数是 replication.factor 和 min.insync.replicas。我整理了一个表格，方便你对照不同场景的配置：

场景	副本数	min.insync.replicas	说明
开发测试	1	1	节省资源，允许数据丢失
普通生产	3	2	容忍 1 个 broker 宕机
高可用生产	3	3	写入性能下降，但数据零丢失
跨机房	3+	2	副本分布在不同机房

注意：min.insync.replicas 设成 3 时，如果有一个 broker 宕机，所有写入都会失败。因为 ISR（In-Sync Replicas）列表里只剩 2 个副本，达不到 3 的要求。所以这个值一般设成副本数减 1。

3.4 消息积压排查：从现象到根因

消息积压是实时推荐平台最常见的故障之一。消费者处理不过来，消息在 Kafka 里越堆越多，延迟越来越大。我遇到过最夸张的一次，积压了 2 亿条消息，延迟超过 6 小时——整个推荐系统基本废了。

排查积压，我一般按这个步骤来：

确认积压量：用 kafka-consumer-groups.sh 查看 Lag
定位瓶颈：是生产者太快，还是消费者太慢？
分析消费者：看消费者实例数、处理耗时、是否有异常
检查资源：CPU、内存、网络、磁盘 IO
制定方案：扩容、优化、降级

先看怎么查积压：

# 查看消费者组的状态和 Lag
kafka-consumer-groups.sh --bootstrap-server kafka01:9092 \
  --group user-click-consumer \
  --describe

# 输出示例
GROUP                TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
user-click-consumer  user-click      0          1000            5000            4000
user-click-consumer  user-click      1          1200            5200            4000
user-click-consumer  user-click      2          800             4800            4000

看到 Lag 很大，别慌。先判断是全局积压还是局部积压。如果所有分区 Lag 都大，说明消费者整体处理能力不足。如果只有个别分区 Lag 大，那可能是数据倾斜或者那个分区对应的消费者实例有问题。

  排查技巧：用 --members --verbose 参数查看消费者实例的分配情况。如果某个消费者实例分配了多个分区，而其他实例分配很少，说明分区分配不均匀。这时候可以重启消费者组，让 Kafka 重新分配。

3.5 消息积压处理：快速止血与根治

积压一旦发生，第一要务是「止血」，别让积压继续扩大。然后再考虑「根治」。

快速止血方案：

增加消费者实例：如果消费者组有空闲分区，直接加实例就能提升消费速度
提升消费并行度：调整消费者内部的线程数、批量大小
临时降级：跳过非核心数据的处理，只处理关键数据
重置消费位点：如果积压数据已经过期或不再需要，直接跳过

我曾经遇到过一个场景：消费者里有个外部 API 调用，响应时间从 10ms 飙升到 2s，导致消费速度骤降。我当时做的第一件事就是把这个 API 调用改成异步，先把消息消费掉，数据落本地，再慢慢处理。嗯，这招叫「先收后算」。

根治方案：

优化消费者逻辑：减少不必要的计算、批量处理、异步化
扩容分区：如果分区数不够，增加分区并重新分配
调整 Kafka 参数：增大 fetch.max.bytes、max.poll.records 等
升级硬件：换 SSD、加内存、升级网络

这里我分享一个排查积压的流程图，方便你快速定位问题：

3.6 日常运维：监控与预防

与其等积压发生了再救火，不如提前做好监控。我个人的习惯是，对每个 Topic 设置以下告警：

Lag 告警：Lag 超过 10000 条或延迟超过 5 分钟
消费速率告警：消费速率低于生产速率的 80%
消费者离线告警：消费者组中实例数减少
磁盘使用率告警：超过 80% 触发预警，超过 90% 触发紧急

监控命令也很简单：

# 定期采集 Lag 数据，写入监控系统
kafka-consumer-groups.sh --bootstrap-server kafka01:9092 \
  --group user-click-consumer --describe \
  | awk 'NR>1 {print $1","$2","$6}' \
  | while IFS=',' read topic partition lag; do
      echo "kafka_lag{topic=\"$topic\",partition=\"$partition\"} $lag"
    done

这段脚本可以配合 Prometheus 的 Pushgateway 或者直接写入 InfluxDB。有了历史数据，你就能看到 Lag 的变化趋势，提前发现潜在问题。

避坑指南：我曾经因为没监控磁盘使用率，导致 Kafka 日志段文件被删除，消费者无法读取数据。后来我加了一个定时任务，每天检查磁盘使用率，超过 85% 就自动清理过期 Topic 或扩容磁盘。

好了，Kafka 数据接入层的运维就聊到这儿。Topic 管理、分区副本策略、消息积压排查，这三块是实时推荐平台的基石。你把这些搞明白了，数据接入层基本不会出大问题。