Kafka acks 和 min.insync.replicas 怎么配置？
面试怎么回答
acks 决定 Producer 等待什么级别的确认，min.insync.replicas 决定 acks=all 时至少需要多少个 ISR 副本。重要链路常用副本数 3、acks=all、最小 ISR 为 2，并配合幂等、重试和 ISR 告警。这样允许一个副本故障后继续写，只剩一个同步副本时则拒绝写入，用短暂可用性换取已确认数据的可靠性。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
很多人直接回答：
“生产环境把 acks 配成 all，这样消息就不会丢。”
acks=all 确实提供了最强的 Producer 确认语义，但它不能脱离副本数、ISR 和 min.insync.replicas 单独理解。
这组参数解决的是：一条消息至少写入多少个同步副本才算成功，以及副本不足时选择失败还是继续写。
先理解 acks 的三种取值
acks=0
Producer 发送后不等待 Broker 确认。
延迟最低，但客户端无法知道消息是否真正写入，通常不适合重要业务数据。
acks=1
Leader 写入本地日志后就返回成功，不等待 Follower 同步。
如果 Leader 刚返回成功就故障，而 Follower 尚未复制完成，这条消息可能在 Leader 切换后丢失。
acks=all
Leader 要等待当前 ISR 完成复制确认后才返回成功，可靠性最高，但副本不足时可能增加延迟或直接写失败。
min.insync.replicas 决定成功下限
min.insync.replicas 表示在 acks=all 条件下，一次写入至少需要多少个 ISR 副本参与，才允许成功。
例如：
replication.factor = 3
acks = all
min.insync.replicas = 2正常情况下，Leader 会等待当前 ISR 完成复制；同时，ISR 数量至少要满足 2 这个写入下限，Producer 才会收到成功。
如果 ISR 只剩 1 个，Broker 会拒绝写入，Producer 收到异常并按重试策略处理。
这意味着系统在副本不足时选择了：
宁可暂时不可写，也不把“只写一个副本”当成成功。
怎么做配置取舍？
重要业务链路
常见组合是副本数 3、acks=all、min.insync.replicas=2，并配置合理重试和幂等 Producer。
它允许损失一个副本后继续写；当只剩一个同步副本时停止确认成功，避免可靠性继续下降。
可容忍少量丢失、极度关注延迟
可以评估 acks=1，但必须明确接受 Leader 故障窗口中的数据风险，不能只说“性能更好”。
不能只改 Producer
还要同时关注：
- Topic 副本数是否足够
- ISR 是否频繁缩小
- Producer 是否启用幂等和合理重试
- Broker 磁盘、网络和副本同步是否稳定
- 副本不足告警是否能及时触达
参数只是最后一道门槛，集群健康决定这道门槛能否长期满足。
一个典型场景
某 Topic 有 3 个副本，但 min.insync.replicas=1。
即使 Producer 使用 acks=all，当 ISR 退化到只剩 Leader 时，写入仍可能被确认成功。此时 Leader 再故障，已确认消息仍存在丢失风险。
把最小 ISR 提高到 2 后，副本只剩 1 个时写入会失败。业务短时间不可写，但不会把低于可靠性底线的写入当成成功。
高可用不是永远写成功，而是在可用性和数据安全之间做清楚的选择。