生而为人

程序员的自我修养

0%

Kafka

Posted on In ,

[toc]

Kafka 削峰填谷 通俗大白话 + 面试标准回答

一、先通俗理解

削峰：业务高峰期流量暴增，下游系统扛不住，先把消息扔到 Kafka 缓存起来，把尖峰削平，不打垮下游。

填谷：业务低峰期没流量了，再慢慢消费缓存里堆积的消息，把空闲时段填满，平稳消化积压。

一句话：Kafka 当中间缓冲区，把突发猛流量，变成平稳匀速流量。

二、核心原理

  1. 上游生产者不管流量多大，直接往 Kafka 发消息；
  2. Kafka 磁盘持久化，能扛海量堆积，不丢数据、不崩；
  3. 下游消费者按自己的处理能力匀速拉取，不被瞬时高峰压垮。

三、为什么能削峰填谷

  1. 高吞吐、可海量堆积

    Kafka 基于磁盘顺序写，支撑百万级 TPS，能存大量积压消息。

  2. 解耦上下游

    上游发消息不用等下游处理完，异步隔离。

  3. 消费者可控消费速率

    下游可以自己控制拉取速度，高峰期慢一点，低峰期补积压。

四、实际业务场景

  1. 电商秒杀、下单峰值

    秒杀瞬间流量爆炸，直接写数据库必崩，先落 Kafka，后端慢慢消费落库。

  2. 日志采集

    客户端瞬间打大量日志，Kafka 承接，Flink/Spark 平稳消费。

  3. 实时数仓、风控事件

    突发行为流量，Kafka 缓冲，避免 Flink 任务反压、OOM。

  4. 订单回调、消息通知

    瞬时回调洪峰，用 Kafka 削峰，避免接口超时、雪崩。

五、面试标准口述版

Kafka 削峰填谷就是利用高吞吐、磁盘持久化可堆积的特性，作为上下游中间缓冲队列；

业务高峰期把突发流量先缓存到 Kafka，削平流量尖峰，避免下游被打垮；

业务低峰期再匀速消费积压消息，利用空闲时间慢慢消化，实现整体流量平稳，起到流量缓冲、系统解耦、保护下游服务的作用。

六、顺带记：削峰填谷带来的好处

  • 流量缓冲，防系统雪崩
  • 上下游异步解耦
  • 峰值不扩容，节省机器成本
  • 消息持久化，不丢数据

Kafka 面试高频 20 题｜极简一句话标准答案（直接背）

基础核心

  1. Kafka 是什么？

    分布式高吞吐消息队列 / 流平台，基于分区 + 副本，持久化、高可用、可堆积。

  2. 核心组件有哪些？

    Producer 生产者、Broker 服务节点、Topic 主题、Partition 分区、Consumer 消费者、ConsumerGroup 消费者组。

  3. Partition 分区作用？

    并行度核心，分区越多吞吐越高；同一分区消息有序。

  4. 副本 Replica 作用？

    做高可用容灾，Leader 负责读写，Follower 同步数据，Leader 挂了自动选主。

  5. Broker 作用？

    Kafka 服务节点，负责接收、存储、转发消息，落地磁盘持久化。

  6. 生产者发送模式？

    同步发送、异步发送、批量发送；生产多用异步批量提升吞吐。

  7. ACK 三个级别含义？

    0：不等落盘直接返回，最快易丢；

    1：Leader 落盘就返回；

    -1/all：Leader + 所有副本都同步完才返回，最安全。

  8. Kafka 为什么快？

    顺序写磁盘、页缓存、零拷贝、批量压缩、分区并行。

有序性 & 消费

  1. Kafka 全局有序吗？

    不全局有序；只保证同一个分区内消息有序。

  2. 如何保证全局有序？

    把所有数据发到同一个分区，缺点是丧失并行度、吞吐低。

  3. 消费者组作用？

    同组内一个分区只能被一个消费者消费，实现负载均衡；不同组可重复消费。

  4. 分区与消费者数量关系？

    消费者数 ≤ 分区数；多于分区的消费者会空闲不干活。

  5. Offset 偏移量是什么？

    分区内消息唯一序号，记录消费者消费到哪，重启接着读不重复不丢。

  6. Offset 存在哪里？

    新版默认存在 Kafka 内置 __consumer_offsets 主题；旧版存 ZK。

可靠性 & 丢失重复

  1. 怎么保证消息不丢？

    生产者开 acks=-1；分区多副本；消费者先消费后提交 offset；开启持久化。

  2. 怎么防止消息重复？

    业务层唯一主键幂等、Redis 去重、Flink/Spark 开启 Checkpoint。

  3. 什么时候会重复消费？

    消费完没提交 offset 就重启、消费者重平衡、会话超时。

  4. 什么是重平衡 Rebalance？

    消费者组成员变化、分区变更触发重新分配分区，期间暂停消费，会影响延迟。

业务原理 & 场景

  1. Kafka 削峰填谷原理？

    利用磁盘可堆积做流量缓冲，高峰缓存流量削尖峰，低峰慢慢消费填空闲，保护下游不被压垮。

  2. Kafka 适用场景？

    系统解耦、流量削峰填谷、日志采集、实时数仓数据源、异步通知、流处理中间缓冲。

Kafka 项目实战坑 + 高频调优要点（面试直接口述版）

一、项目常见坑（必背，面试最爱问）

1. 消息丢失

现象：生产者发了，消费者收不到。

原因

  • acks=0/1 网络抖动丢消息

  • 消费者手动提交 offset 过早

  • 机器宕机、分区副本没同步

    解决

  • 重要业务 acks=-1

  • 消费处理完成再提交 offset

  • 配置多副本、开启磁盘持久化

2. 消息重复消费

现象：同一条数据反复消费，入库重复。

原因

  • 业务处理完，offset 还没提交就重启

  • 消费者重平衡、会话超时

  • 自动提交时机不合理

    解决

  • 业务唯一主键幂等写入

  • Redis / 布隆过滤器去重

  • 关闭自动提交，手动批量提交 offset

3. 消费乱序

现象：业务日志时间错乱，对账对不上。

原因

  • 并发多分区，只能保证单分区有序

  • 发到不同分区导致全局无序

    解决

  • 同业务 key 哈希打到同一个分区

  • 要全局有序就单分区（牺牲吞吐）

4. 消费者重平衡频繁

现象：时不时停几秒、消费卡顿、延迟飙升。

原因

  • 心跳超时、会话时间设置过小

  • 消费者上下线频繁

  • 网络抖动

    解决

  • 调大 session.timeout、心跳间隔

  • 稳定消费者实例数，避免频繁启停

5. 分区数不合理

分区太少：并行度上不去，消费延迟堆积

分区太多：元数据压力大、重平衡频繁、占用过多 socket

解决

分区数 = 消费并行度，和 Flink/Spark 并行度对齐。

6. 消息积压

现象：消费速度跟不上生产，offset 一直往后堆，延迟越来越大。

原因

  • 下游处理太慢、逻辑太重

  • 消费并行度不够、分区少

  • 资源不足、GC 频繁

    解决

  • 优化消费业务逻辑，前置过滤

  • 增加分区 + 提高消费者并行度

  • 高峰期临时扩容消费者

现象：分区长时间没数据，Flink 窗口不触发。

解决

标记空闲分区，允许空闲流，保证水位线正常推进。

8. 小消息吞吐量低、网络开销大

现象：大量小消息，频繁网络请求，吞吐上不去。

解决

开启批量发送、消息压缩，攒批再发。

9. 磁盘爆满、日志保留策略没配

现象：Kafka 磁盘持续上涨，机器告警。

解决

配置保留时间 + 保留大小，自动清理旧消息；业务做好离线落库备份。

二、Kafka 生产调优全套（面试直接背）

1. 生产者调优

  • acks=-1 保证可靠不丢
  • 开启批量发送、压缩（lz4/snappy）
  • 增加重试次数、配置发送缓冲区
  • 关键业务异步发送 + 回调日志记录失败消息

2. 消费者调优

  • 关闭自动提交，手动提交 offset
  • 合理设置会话超时、心跳时间，减少重平衡
  • 批量拉取数据，提高单次处理吞吐
  • 消费逻辑异步化，避免阻塞 poll

3. 分区与副本调优

  • 分区数和消费并行度严格对齐
  • 生产至少 3 副本，高可用防宕机
  • 不要盲目加分区，避免元数据压力过大

4. 集群服务端调优

  • 配置消息保留时长、磁盘上限自动清理
  • 优化页缓存、磁盘刷盘策略
  • 控制单分区日志大小、分段日志尺寸
  • 均衡 leader 分区分布，避免节点压力不均
  • Kafka 分区数 = Flink/Spark 并行度
  • 开启 CK，offset 随状态一致性保存
  • 不随意重置 offset，防止重复 / 丢数据

三、面试 30 秒总结口述

项目中 Kafka 主要遇到消息丢失、重复消费、消费乱序、频繁重平衡、数据积压、分区不合理、磁盘爆满等问题；

调优从生产者 acks 与批量压缩、消费者手动提交 offset 与会话参数、分区副本规划、集群保留策略、与实时引擎并行度对齐几方面入手，配合业务幂等，保证高吞吐、不丢不重、稳定低延迟。