案例 01
Kafka 生产集群从零搭建（5 节点 + SASL 认证）
背景描述
某金融企业需要建设实时数据总线，日处理消息量约 50 亿条。要求高可用（容忍 2 节点故障）、数据持久化、SASL/SCRAM 认证、Topic 级别的 ACL 权限控制。
解决方案
部署 5 节点 Kafka 集群（Broker ID 0-4），使用 Zookeeper 3 节点独立部署。配置 SASL_SCRAM-SHA-512 + ACL。Topic 设置 replication-factor=3, min.insync.replicas=2。
技术要点
- Broker 配置：num.partitions=12, default.replication.factor=3, min.insync.replicas=2
- 磁盘规划：每节点 4 块 SSD RAID0，log.dirs 多目录并行读写
- SASL/SCRAM 认证 + ACL：区分生产者/消费者/管理员角色
- JVM 调优：堆内存 6G（Kafka 建议不超过 8G），使用 G1GC
# server.properties 关键配置
broker.id=0
listeners=SASL_PLAINTEXT://0.0.0.0:9092
advertised.listeners=SASL_PLAINTEXT://kafka-01.example.com:9092
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
sasl.enabled.mechanisms=SCRAM-SHA-512
num.partitions=12
default.replication.factor=3
min.insync.replicas=2
log.dirs=/data/kafka/disk1,/data/kafka/disk2,/data/kafka/disk3,/data/kafka/disk4
num.network.threads=8
num.io.threads=16
# 创建 SCRAM 用户
kafka-configs.sh --zookeeper zk1:2181 --alter \
--add-config 'SCRAM-SHA-512=[password=producer-secret]' \
--entity-type users --entity-name producer
kafka-configs.sh --zookeeper zk1:2181 --alter \
--add-config 'SCRAM-SHA-512=[password=consumer-secret]' \
--entity-type users --entity-name consumer
# 创建 Topic（3 副本，min.insync=2）
kafka-topics.sh --bootstrap-server kafka-01:9092 --create \
--topic order-events --partitions 24 --replication-factor 3 \
--config min.insync.replicas=2 --config retention.ms=604800000
案例 02
Kafka 消费者 Lag 堆积故障排查与处理
背景描述
电商大促期间，订单消费者 Lag 从正常 200 飙升到 500 万，订单处理延迟超过 1 小时。消费者组有 6 个实例，但只有 2 个在真正消费消息。
解决方案
通过 kafka-consumer-groups 定位问题：Topic 只有 12 个 Partition，但消费者 6 个实例只分配了 2 个（4 个因 group.id 配置错误在空闲）。紧急修正 group.id 后，调整分区数为 24 并 Rebalance。
技术要点
- kafka-consumer-groups.sh --describe 查看 Lag 和分区分配情况
- 问题根因：新加实例的 group.id 与旧实例不一致，Kafka 创建了新的 Consumer Group
- 增加 Partition 数到 24（Kafka 仅支持增加不支持减少），重组消费者组
- 优化消费逻辑：批量拉取 + 异步处理，单次拉取从 1 条改为 max.poll.records=500
# 查看 Consumer Group Lag
kafka-consumer-groups.sh --bootstrap-server kafka-01:9092 \
--group order-consumer --describe
# 关键输出：LAG 列显示堆积量，CURRENT-OFFSET vs LOG-END-OFFSET
# 增加分区（注意：不能减少！）
kafka-topics.sh --bootstrap-server kafka-01:9092 \
--alter --topic order-events --partitions 24
# 消费者配置优化
# max.poll.records: 500（增大批量处理）
# max.poll.interval.ms: 600000（10 分钟，防止被踢出组）
# auto.offset.reset: earliest（新加入消费者从头消费）
# 堆积消费加速脚本（多实例并行）
for i in $(seq 1 6); do
kafka-console-consumer.sh --bootstrap-server kafka-01:9092 \
--topic order-events --group order-consumer --from-beginning &
done
案例 03
Kafka 磁盘写满导致 ISR 缩容故障
背景描述
凌晨 Kafka 日志写满 /data 分区（100%），部分 Broker IO 线程阻塞，多个 Topic 的 ISR（In-Sync Replicas）从 3 降为 1，数据可靠性严重受损。
解决方案
紧急清理过期 Segment（调整 retention 策略），临时挂载 NFS 扩容存储空间。事后调整 Topic 保留策略为按大小限制（retention.bytes），并规划独立的日志存储分区。
技术要点
- ISR 缩容意味着 Follower 落后太多被踢出 ISR，一旦 Leader 故障可能丢数据
- 短期方案：调整 retention.ms 从 7 天改为 3 天，手动删除过期 Segment
- 长期方案：配置 retention.bytes=100GB per Topic，结合 log.segment.bytes 控制文件大小
- 监控：Kafka JMX → Prometheus jmx_exporter 采集 Broker 磁盘使用率、ISR 数量
# 查看 ISR 状态
kafka-topics.sh --bootstrap-server kafka-01:9092 \
--describe --topic order-events
# 关注：Isr 列应等于 Replicas 列
# 调整 Topic 保留策略
kafka-configs.sh --bootstrap-server kafka-01:9092 \
--alter --entity-type topics --entity-name order-events \
--add-config retention.ms=259200000,retention.bytes=107374182400
# jmx_exporter 配置（Prometheus 集成）
# kafka-run-class.sh 启动时附加
export KAFKA_OPTS="-javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar=7071:/opt/jmx_exporter/kafka-2_0_0.yml"
# Kafka JMX 关键指标
# kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions
# kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
# kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec