【MS核心】组件：Kafka

一、基础核心（必背）

1. Kafka 是什么？核心特性

• 定义：Apache 开源的分布式流处理平台（本质是分布式消息队列），基于“主题-分区”模型，主打高吞吐、高可用、持久化；
• 核心特性：
  • 高吞吐：支持千万级 TPS（磁盘顺序写+批量处理）；
  • 高可用：分区副本机制（多副本备份）、集群部署无单点故障；
  • 持久化：消息写入磁盘，支持数据回溯（按 Offset 重新消费）；
  • 高并发：支持多生产者、多消费者同时读写；
  • 流处理：集成 Flink/Spark 等流处理框架，支持实时数据处理。

2. 核心架构（高频考点）

（1）核心组件及作用

（2）核心流程（生产者发消息→消费者收消息）

1. Producer 发送消息到 Topic，按路由规则（如 Key 哈希、轮询）分配到对应 Partition；
2. 消息写入 Partition 的 Leader 副本（顺序写磁盘），Follower 副本异步同步 Leader 数据；
3. Consumer 所在消费组订阅 Topic，Consumer 拉取对应 Partition 的 Leader 消息；
4. 消费成功后，Consumer 提交 Offset（消费进度），下次从下一个 Offset 继续拉取。

二、核心特性与原理（面试重中之重）

1. 分区与副本机制（高可用+高吞吐核心）

（1）分区（Partition）核心

• 作用：
  • 水平扩展：Topic 分区数越多，并发读写能力越强（每个分区独立读写）；
  • 负载均衡：消息分散存储在多个 Broker，避免单节点压力过大；
  • 顺序保证：分区内消息有序（全局无序，除非 Topic 只有 1 个分区）；
• 分区路由规则（Producer 发送消息时）：
  • 指定 Partition：直接发送到目标 Partition；
  • 指定 Key：hash(Key) % 分区数 分配到固定 Partition（保证同一 Key 消息有序）；
  • 未指定 Key：轮询分配（负载均衡）。

（2）副本（Replica）核心

• 副本同步：Follower 主动拉取 Leader 消息日志（Log），保持数据一致；
• Leader 选举：
  • 触发条件：Leader 宕机、Broker 离线、网络分区；
  • 选举规则：基于 AR（Assigned Replicas，分区所有副本）中的 ISR（In-Sync Replicas，与 Leader 同步的副本）选举，优先选择 ISR 中存活且同步进度最新的副本；
  • 安全机制：只有当消息被 ISR 中所有副本同步后，才视为“已提交”（Committed），避免数据丢失。

2. 消息存储机制（高性能核心）

（1）存储结构

• 每个 Partition 对应磁盘上一个目录（topic-分区号），包含：
  • 日志文件（Log Segment）：多个分段文件（如 00000000000000000000.log），每个文件默认 1GB（可配置），文件名=起始 Offset；
  • 索引文件（.index/.timeindex）：对应日志文件的索引，加速消息查找（通过 Offset/时间戳定位日志位置）；
• 存储优化：
  • 顺序写日志：磁盘顺序 IO 性能接近内存（避免随机写的寻道时间）；
  • 批量刷盘：消息先写入页缓存（PageCache），后台线程批量刷盘（减少磁盘 IO 次数）；
  • 日志清理：按保留策略（时间/大小）删除过期日志（默认保留 7 天）。

（2）消息可靠性等级（acks 参数）

• acks=0：生产者发送消息后立即返回成功，不等待 Broker 确认（可能丢失数据，性能最高）；
• acks=1：生产者等待 Leader 写入消息后返回成功（Leader 宕机可能丢失数据，默认）；
• acks=-1（all）：生产者等待 ISR 中所有副本同步完成后返回成功（无数据丢失，性能最低）；
• 选型：金融级场景用 acks=-1，普通场景用 acks=1，性能优先场景用 acks=0。

3. 消费机制（核心）

（1）消费组与 Partition 映射规则

• 核心原则：一个 Partition 只能被同一个消费组内的一个 Consumer 消费（避免重复消费）；
• 映射逻辑：Consumer Group 内的 Consumer 数量 ≤ Partition 数量（否则多余 Consumer 空闲）；
• 重平衡（Rebalance）：
  • 触发条件：Consumer 加入/退出消费组、Topic 分区数变化；
  • 过程：暂停所有 Consumer 消费→重新分配 Partition→恢复消费；
  • 问题：重平衡期间消息消费暂停，可能导致重复消费（需业务幂等）。

（2）Offset 管理（消费进度）

• Offset 定义：每个消息在 Partition 中的唯一序号（递增），标记消费进度；
• 存储位置：
  • Kafka 0.9 前：存储在 Zookeeper（性能低，不支持高并发）；
  • Kafka 0.9 后：存储在 Kafka 内置 Topic（__consumer_offsets），由 Broker 管理（推荐）；
• 提交方式：
  • 自动提交：默认每隔 5 秒提交一次（enable.auto.commit=true），可能导致重复消费（消费后未提交 Offset 崩溃）；
  • 手动提交：业务显式调用 commitSync（同步）/commitAsync（异步）提交（推荐，确保消费成功后提交）。

（3）消费模式

• 集群消费（默认）：消息只被消费组内一个 Consumer 消费（负载均衡）；
• 广播消费：消息被所有消费组消费（每个消费组独立维护 Offset，通过创建多个消费组实现）。

4. 高可用设计（核心考点）

（1）集群高可用

• Broker 集群：多节点部署，每个 Partition 分散在不同 Broker；
• 副本备份：每个 Partition 至少 3 个副本（1 Leader + 2 Follower），避免单节点故障；
• 无单点故障：Zookeeper 集群（协调）+ Broker 集群（存储）+ 副本机制（数据备份）。

（2）数据可靠性保证

• 生产端：acks=-1（ISR 全同步）+ 重试机制（retries>0）+ 批量发送；
• 存储端：副本同步（ISR 机制）+ 顺序写+批量刷盘；
• 消费端：手动提交 Offset + 业务幂等；
• 关键机制：ISR 列表动态调整（Follower 同步延迟超过阈值会被移出 ISR，恢复后重新加入）。

5. 关键优化参数（实战高频）

三、常见问题与解决方案（实战高频）

1. 消息丢失问题

• 可能原因：
  • 生产端：acks=0/1 时 Leader 宕机、网络异常未重试；
  • 存储端：Follower 未同步完成 Leader 宕机、日志未刷盘 Broker 崩溃；
  • 消费端：自动提交 Offset 后业务执行失败；
• 解决方案：
  • 生产端：acks=-1 + retries>0 + 批量发送；
  • 存储端：副本数≥3 + 最小同步副本数（min.insync.replicas=2）；
  • 消费端：手动提交 Offset + 消费成功后再提交。

2. 消息重复消费问题

• 可能原因：
  • 生产端：重试机制导致消息重复发送；
  • 消费端：重平衡、网络波动导致 Offset 未提交成功，重新拉取；
  • Broker ：Leader 切换导致消息重复投递；
• 解决方案：
  • 业务幂等设计（核心）：用消息 Key（如订单 ID）或 Kafka 内置消息 ID（offset）去重；
  • 消费端：减少重平衡频率（避免频繁增减 Consumer）、手动提交 Offset 时做好幂等校验。

3. 消息积压问题

• 可能原因：
  • 生产端：消息发送速率远超消费速率；
  • 消费端：消费逻辑耗时过长、Consumer 数量不足（小于 Partition 数）、拉取参数配置不合理；
• 解决方案：
  • 临时扩容：增加 Consumer 数量（不超过 Partition 数）、提升消费线程池大小；
  • 优化消费逻辑：异步消费、拆分复杂任务、批量拉取（增大 fetch.min.bytes）；
  • 生产端限流：避免消息过量涌入；
  • 数据迁移：将积压消息迁移到临时 Topic，分批次消费。

4. 重平衡（Rebalance）问题

• 危害：重平衡期间消费暂停，导致消息积压；可能引发重复消费；
• 优化方案：
  • 避免频繁增减 Consumer（如用容器化部署时设置合理的扩容阈值）；
  • 配置合理的会话超时时间（session.timeout.ms=30000ms）和心跳间隔（heartbeat.interval.ms=10000ms）；
  • 用 Kafka 2.4+ 引入的增量重平衡（Incremental Rebalance），减少暂停时间。

5. 数据倾斜问题

• 现象：部分 Consumer 消费压力大（处理大量消息），其他 Consumer 空闲；
• 原因：Partition 分配不均、消息 Key 分布不均（如某类 Key 消息占比极高）；
• 解决方案：
  • 优化 Key 分布：避免 Key 集中，用随机后缀打散 Key；
  • 调整分区数：增加 Partition 数量，使消息分布更均匀；
  • 自定义分区器：按业务场景重新分配消息到 Partition。

四、与 RocketMQ/RabbitMQ 对比（面试必问）

五、高频实战问题（面试必问）

1. Kafka 的高可用设计是什么？
   答：① 分区副本机制（1 Leader + N Follower，数据多备份）；② ISR 同步机制（确保消息被多数副本同步，避免数据丢失）；③ Leader 选举（Leader 宕机后 Follower 自动上位）；④ 集群部署（Broker/ZK 集群无单点故障）。

2. Kafka 的 ISR 机制是什么？
   答：ISR（In-Sync Replicas）是与 Leader 保持同步的副本集合。Leader 会跟踪 ISR 列表，只有消息被 ISR 中所有副本同步后才视为“已提交”；Follower 同步延迟超过阈值（replica.lag.time.max.ms）会被移出 ISR，恢复后重新加入，保证数据一致性和可用性。

3. 消息丢失、重复消费、积压的解决方案？
   答：丢失：生产端 acks=-1+重试，存储端副本数≥3，消费端手动提交 Offset；重复：业务幂等（消息 Key 去重）；积压：扩容 Consumer、优化消费逻辑、生产端限流。

4. Kafka 为什么吞吐量高？
   答：① 顺序写磁盘（避免随机写寻道时间）；② 批量发送/拉取（减少网络 IO 和磁盘 IO 次数）；③ 页缓存（PageCache）减少磁盘直接访问；④ 分区并行读写（水平扩展）；⑤ 零拷贝技术（数据从磁盘→内核缓冲区→网络缓冲区，无需应用层拷贝）。

5. Kafka 的 Offset 是如何管理的？
   答：Offset 是消息在 Partition 中的唯一序号，标记消费进度。Kafka 0.9 后 Offset 存储在内置 Topic（__consumer_offsets），支持自动提交（默认 5 秒）和手动提交（commitSync/commitAsync）；关键业务推荐手动提交，确保消费成功后再提交。

6. Kafka 与 RocketMQ 的区别？如何选型？
   答：Kafka 吞吐量更高，流处理生态完善，适合日志采集、大数据流处理；RocketMQ 支持事务/延时/顺序等复杂消息类型，适配 Java 微服务生态，适合互联网/电商/金融场景。

六、核心原则（面试总结）

1. 架构核心：分区+副本机制，兼顾高吞吐（分区并行）和高可用（副本备份）；
2. 性能核心：顺序写+批量处理+页缓存+零拷贝，最大化磁盘和网络 IO 效率；
3. 可靠性核心：ISR 同步机制+acks 参数+Offset 手动提交，层层保障数据不丢失；
4. 实战重点：消息可靠性保证、重平衡优化、数据倾斜解决、参数调优；
5. 选型原则：高吞吐/流处理/日志采集选 Kafka，复杂消息场景（事务/延时/顺序）选 RocketMQ。