Kafka 的写入路径是先写 Leader，再由 Leader 复制到 Followers。
对生产者而言是否等 Followers取决于 acks（确认级别）。
不存在生产者直接同时写 Leader 和 Follower的机制，复制由 Leader 侧串起完成。
写入链路：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 拉取是为了在吞吐、顺序、一致性与故障恢复之间取平衡，而不是追求生产者侧的并行多写。