一、Kafka核心架构原理
1. 分布式协调与选举
- Controller选举：Kafka集群中首个在ZooKeeper创建
/controller节点的Broker成为Controller（或使用KRaft协议去ZK化） - Partition Leader选举：Controller监控ISR变化，优先从ISR列表中选举新Leader（默认
unclean.leader.election.enable=false确保数据一致性）
2. ISR、OSR与HW机制
- ISR (In-Sync Replicas)：与Leader保持同步的副本集合（包含Leader自身）
- OSR (Out-of-Sync Replicas)：滞后超过
replica.lag.time.max.ms的副本 - HW (High Watermark)：所有ISR副本均已复制的最大偏移量，消费者可见的数据分界点
- LEO (Log End Offset)：当前副本最新消息的偏移量
关键公式：
HW = min(Leader_LEO, Follower1_LEO, Follower2_LEO, ...)
3. 高性能存储设计
- Segment分片存储：
- 每个Partition拆分为多个Segment（默认1GB）
- 文件命名基于基准偏移量（如
00000000000036876912.log） - 包含
.log（数据）、.index（稀疏索引）、.timeindex（时间索引）
- 内存映射优化：通过
FileChannel.map()实现零拷贝读取
4. 刷盘机制 (Flush)
- Page Cache优先：消息先写入OS页缓存，由操作系统异步刷盘
- 同步刷盘策略：
flush.messages：累计n条消息强制刷盘flush.ms：间隔n毫秒强制刷盘
- 权衡建议：通常采用异步刷盘（
log.flush.interval.messages=10000）平衡性能与可靠性
5. 消息压缩算法
| 算法 | 压缩比 | CPU消耗 | 适用场景 |
|---|---|---|---|
| gzip | 最高 | 高 | 带宽敏感场景 |
| snappy | 中等 | 低 | CPU敏感场景（默认） |
| lz4 | 中等 | 最低 | 低延迟场景 |
| zstd | 高 | 中等 | Kafka 2.1+ 平衡选择 |
生产者端设置compression.type启用压缩，Broker保持压缩状态存储。
二、高可用与消息可靠性保障
1. 数据高可用策略
- Replica同步流程：
- Producer发送消息至Leader
- Leader持久化消息并更新LEO
- Followers从Leader拉取消息（PULL模式）
- Follower持久化后返回ACK
- Leader更新HW并通知Followers
- ACK确认机制：
acks=0：不等待确认（可能丢失数据）acks=1：Leader落盘即确认（默认）acks=all：所有ISR副本落盘确认（最强保障）
2. 消息丢失场景与规避
| 场景 | 解决方案 |
|---|---|
| Producer端丢失 | 设置acks=all + retries=N |
| Broker端丢失 | min.insync.replicas=2 |
| Consumer端丢失 | 关闭自动提交，处理完手动提交 |
3. 顺序消费保证
- 关键条件：单分区内消息天然有序
- 消费端策略：
- 使用单线程消费分区
- 对Key做哈希路由，相同Key的消息发往同一分区
- 避免分区重平衡导致乱序（
max.poll.interval.ms调优）
三、Kafka高频面试题精析
1. HW截断机制是什么？
当Leader切换时，新Leader会将其HW设置为当前LEO，Follower比较自身HW与Leader的HW，将本地日志截断到HW位置，确保数据一致。
2. Kafka为什么快？
- 零拷贝技术（
sendfile系统调用） - 顺序磁盘I/O（Segment追加写入）
- 页缓存（Page Cache）加速读写
- 批量处理（Producer/Broker/Consumer）
3. 如何避免重复消费？
- 幂等Producer：启用
enable.idempotence=true，自动去重 - 事务消息：跨会话精确一次语义（EOS）
- 消费端：保证处理逻辑幂等性（如数据库唯一键）
4. Rebalance触发的条件？
- 消费者组新增/退出实例
- 订阅Topic分区数变化
- 消费者超过
session.timeout.ms未发送心跳