面试全系列之【Kafka】之【经典版】系列

1. Kafka 为什么高吞吐？

1. 顺序读写：磁盘顺序写远快于随机写。
2. PageCache：利用操作系统缓存，不直接刷磁盘。
3. 零拷贝：sendfile 减少内核态与用户态拷贝。
4. 批量发送 & 压缩：消息批量提交，支持 gzip、snappy 等压缩。
5. 分区并行：Topic 多分区，实现分布式并行消费与生产。

2. Kafka 如何保证消息不丢失？

生产者发丢 → Broker 存丢 → 消费者丢，加固

• 生产者

  • acks=all
  • 开启重试（网络抖动、Leader重新选举造成没法出去。）
  • 回调处理失败（防止，失败了之后消息默默丢了。）
  • 可开启幂等防止重复（幂等之后，才能大胆重试。）

• Broker

  • 副本数 ≥ 2
  • min.insync.replicas ≥ 2 . ISR 最小副本数设置
  • unclean.leader.election.enable=false（禁止不干净 Leader 选举，ISR都挂了）

• 消费者

  • 关闭自动提交
  • 业务执行成功后手动提交 offset（异步消费消息。）

3. Kafka 消息重复消费怎么解决？

重复原因：网络抖动、消费者挂掉、offset 未及时提交

生产者到Broker：重试+幂等+事务 解决：不丢、不重、不乱的问题。（精准一次性）

1. 重试：保证消息不丢

• 网络超时、Leader 切换、异常时，生产者重新发送====作用：确保消息一定能发到 Broker

2. 幂等：保证重复发送不重复写入

• 用 PID + sequenceNumber 去重====作用：重试多少次，Broker 只存一条

3. 事务：保证跨分区、批量消息原子性

• 把多条消息、多个分区、甚至 offset 提交包在一个事务里====作用：要么全成功，要么全失败

Broker对消息重复消费与否没有贡献。

消费者必须做好业务方的幂等消费。

使用消息ID进行去重

利用数据库唯一索引

Redis记录ID，先查在处理。

解决方案：

1. 生产者开启幂等生产者（enable.idempotence=true）+ 事务。Kafka精准一次性
2. 消费者端做业务幂等 ：
   • 用唯一消息 ID 去重
   • 利用数据库唯一约束
   • Redis 记录已处理 ID，先查再处理