1. Kafka 为什么高吞吐？
- 顺序读写：磁盘顺序写远快于随机写。
- PageCache：利用操作系统缓存，不直接刷磁盘。
- 零拷贝：sendfile 减少内核态与用户态拷贝。
- 批量发送 & 压缩：消息批量提交，支持 gzip、snappy 等压缩。
- 分区并行：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：重试+幂等+事务 解决：不丢、不重、不乱的问题。（精准一次性）
- 重试：保证消息不丢
- 网络超时、Leader 切换、异常时，生产者重新发送====作用：确保消息一定能发到 Broker
- 幂等：保证重复发送不重复写入
- 用 PID + sequenceNumber 去重====作用：重试多少次，Broker 只存一条
- 事务：保证跨分区、批量消息原子性
- 把多条消息、多个分区、甚至 offset 提交包在一个事务里====作用：要么全成功，要么全失败
Broker对消息重复消费与否没有贡献。
消费者必须做好业务方的幂等消费。
使用消息ID进行去重
利用数据库唯一索引
Redis记录ID，先查在处理。
解决方案：
- 生产者开启幂等生产者（enable.idempotence=true）+ 事务。Kafka精准一次性
- 消费者端做业务幂等 ：
- 用唯一消息 ID 去重
- 利用数据库唯一约束
- Redis 记录已处理 ID，先查再处理