网易一面：KAFKA写入数据时是先写Leader还是先写Follower?

文章内容收录到个人网站，方便阅读：hardyfish.top/

Kafka 的写入路径是先写 Leader，再由 Leader 复制到 Followers。

写入链路：Leader 串行落盘，Followers 异步拉取复制

一次写入在分区（partition）维度上发生：

• 生产者把记录发给该分区的 Leader 副本（leader replica）。
• Leader 将记录追加到本地日志（log）并更新高水位相关状态。
• 各 Follower 副本并不接受生产者写入，而是通过复制线程向 Leader 发起 Fetch 拉取新数据，写入各自本地日志。
• 当副本赶上并满足条件时，Leader 推进 HW（High Watermark，高水位），表示已提交（committed）的偏移。

因此，从时序看是：生产者 → Leader 写入 → Followers 拉取复制。

Followers 的写入相对 Leader 是滞后的，滞后程度由网络、磁盘、负载与副本数共同决定。

acks 决定写到哪一步才算成功

生产者感知到的写成功由 acks 决定：

• acks=0：生产者不等任何确认。
  • Leader 是否写入、Follower 是否复制都不保证，吞吐高但丢数据风险最大。
• acks=1：Leader 写入本地日志后返回确认。
  • Followers 可能还没复制完成。
  • Leader 宕机且数据尚未复制时可能丢失。
• acks=all（或 acks=-1）：
  • Leader 不仅要写入，还要等待数据被复制到 **ISR（In-Sync Replicas，同步副本集合）**中的足够副本后再确认。
  • 通常语义是至少写到所有 ISR 副本，更接近强持久，但延迟更高。

这里的关键点是：即便 acks=all，也是 Leader 等 Followers 复制完成后再回 ACK，而不是生产者并行写多份。

提交可读与已写入不是同一件事

Kafka 有两个容易混淆的状态：

• 已写入（written）：Leader 日志已经追加了这条记录。
• 已提交（committed）：记录的偏移不超过 HW，意味着已被 ISR 复制到位。
  • 消费者在默认隔离级别下通常只会稳定读取到 committed 数据。

当 acks=1 时，写入成功返回可能早于 committed。

当 acks=all 时，返回更接近 committed（在 ISR 机制正常工作前提下）。

常见误区：以为同时写能降低复制延迟

直觉上生产者同时写多个副本似乎更快，但 Kafka 的一致性与顺序保证依赖 Leader 统一仲裁与定序：

• 单点定序：Leader 负责为分区内消息分配顺序与 offset。
• 复制一致：Followers 通过同一个 Leader 拉取同一条日志流，保证副本间顺序一致。
• 故障切换：ISR 与 HW 机制围绕 Leader 的状态推进，简化一致性判断。

因此，Kafka 选择Leader 写入 + Followers 拉取是为了在吞吐、顺序、一致性与故障恢复之间取平衡，而不是追求生产者侧的并行多写。