🚀 Kafka 原理

1. Kafka 的核心架构？

• Broker：Kafka 服务节点（集群由多个 Broker 组成）
• Topic / Partition：Topic 分成多个 Partition，每个 Partition 是有序的日志文件（append-only）
• 分区副本（Replica）：每个 Partition 有多个副本（默认 1 主多从），主副本（Leader）读写，从副本（Follower）同步——读写都在 Leader，Kafka 不做读负载均衡（区别于 MySQL 从库读）
• Controller：集群管理器（选 Leader 的 Leader、分区分配），早期依赖 ZooKeeper，KRaft 模式（3.3+）去 ZK
• Consumer Group：组内分区分配消费（一个分区同一时刻只能被组内一个消费者消费）
• Offset：消费者提交的消费位点，存内部 topic（__consumer_offsets）

Producer → 按 key 哈希选分区 → 发送到 Leader 分区
→ Leader 写日志（磁盘顺序写）→ Follower 拉取同步
→ Consumer 组内分配分区 → 拉取（pull）消息 → 消费 → 提交 offset

2. Kafka 为什么吞吐高？（必考）

1. 顺序写盘：分区日志只追加（append-only），磁盘顺序写 ≈ 内存写速度（机械盘顺序 100MB+/s）；对比随机写慢 100 倍
2. 页缓存（PageCache）：读写走 OS 页缓存，读写快；零拷贝——消费者读取时用 sendfile（磁盘 → socket 直接传输），省去内核态↔用户态 4 次拷贝
3. 批量与压缩：生产者攒批发送（batch），Broker 批量存储，消费者批量拉取；消息压缩（lz4/zstd）降低网络与磁盘
4. 分区并行：多分区多消费者并行，吞吐随分区数扩展
5. 顺序 IO + 无锁设计：单分区单线程写，减少锁竞争

3. acks 参数与 ISR 机制？

• acks=0：发完即算成功（可能丢）——吞吐最高，日志类可接受
• acks=1：Leader 写入成功即返回——Leader 挂了可能丢（未同步到副本）。Kafka 2.x 及以前的默认值
• acks=all（-1）：ISR 中所有副本都同步成功才返回——最可靠，配合 min.insync.replicas。Kafka 3.0 起（KIP-679）这是默认值，同时 enable.idempotence 默认 true

ISR（In-Sync Replicas）：与 Leader 保持同步的副本集合。Follower 落后超过 replica.lag.time.max.ms（默认 30s）会被踢出 ISR（落后副本不能参与选举，防数据丢失）。acks=all 时只有 ISR 内副本确认才算成功。

选举：Leader 挂了从 ISR 中选新 Leader（优先 ISR 内、副本数最全者）。

4. 分区策略与消费者重平衡（Rebalance）？

分区策略：key 为空 → 轮询/粘性（sticky）；key 非空 → hash(key) % 分区数（相同 key 进同一分区 → 保序）。

Rebalance：消费者组成员变化（加入/离开/崩溃）或分区变化时，重新分配"消费者 ↔ 分区"关系。痛点：Stop-The-World——期间整个组停止消费（老版本），且可能重复消费。新版（增量协调器/static membership）改善。