消息可靠性基石：ACKS 参数深度解析
在 Kafka 消息可靠性体系中，acks 是生产者端最核心的配置参数，它直接决定了生产者等待 broker 确认的时机与方式。结合 min.insync.replicas 与 unclean.leader.election.enable，三者共同构成了消息“不丢不重”的底层保障。本节从参数语义、组合效果、压测影响三个维度进行深度拆解。
3.1 acks 参数：三种确认模式
生产者通过 acks 参数控制消息发送后需要等待多少个副本确认写入成功。Kafka 提供三个等级：0、1、all（或 -1）。
| acks 值 | 确认时机 | 数据可靠性 | 吞吐量 | 典型场景 |
|---|---|---|---|---|
| 0 | 不等待任何确认 | 极低，可能丢消息 | 最高 | 日志、监控、可容忍丢失的指标 |
| 1 | 等待 leader 写入本地日志即返回 | 中等，leader 宕机可能丢 | 高 | 大部分业务消息，允许少量丢失 |
| all | 等待所有 ISR 副本确认写入 | 最高，不丢消息 | 较低 | 金融、订单、事务消息 |
压测建议：在可靠性压测中，必须分别测试 acks=0、1、all 三种模式下的吞吐量与延迟曲线。acks=all 时，生产端延迟通常比 acks=1 高 2~5 倍，具体取决于 ISR 副本数量与网络往返时间。
3.2 min.insync.replicas：最小同步副本数
min.insync.replicas 是 topic 级别或 broker 级别的配置，定义了分区 ISR 列表中至少需要多少个同步副本，生产者才能成功写入 acks=all 的消息。如果 ISR 数量低于该值，生产者会收到 NotEnoughReplicasException。
- 默认值：1
- 推荐生产值：2（配合副本因子 3）
- 作用：防止 leader 单独确认后宕机导致消息丢失
关键公式：消息不丢条件 = (acks=all) AND (min.insync.replicas > 1) AND (副本因子 > min.insync.replicas)
3.3 unclean.leader.election.enable：非 ISR 副本选举
当 leader 宕机且 ISR 列表为空时，Kafka 是否允许从非 ISR 副本（即落后副本）中选举新 leader。该参数默认 false（推荐生产环境保持关闭）。
| 参数值 | 行为 | 风险 | 可用性影响 |
|---|---|---|---|
| false | 不允许非 ISR 副本成为 leader | 分区不可用，直到 ISR 恢复 | 降低可用性，保证数据一致性 |
| true | 允许非 ISR 副本成为 leader | 可能丢失已提交消息，数据不一致 | 提高可用性，牺牲一致性 |
压测陷阱：在故障注入测试中，如果 unclean.leader.election.enable=true，即使 acks=all 且 min.insync.replicas=2，仍可能发生消息丢失。因为新 leader 可能不包含之前已确认的消息。这是 Kafka 可靠性测试中最容易被忽视的“一致性漏洞”。
3.4 三参数协同工作流
下图展示了生产者发送消息时，acks、min.insync.replicas 与 unclean leader 选举的完整交互流程：
3.5 压测配置推荐矩阵
根据不同的可靠性等级，以下配置组合可作为压测基准：
| 可靠性等级 | acks | min.insync.replicas | unclean.leader.election | 副本因子 | 预期吞吐损失 |
|---|---|---|---|---|---|
| 最高可靠性 | all | 2 | false | 3 | 基准（100%） |
| 中等可靠性 | 1 | 1 | false | 2 | 提升 40%~60% |
| 高性能模式 | 0 | 1 | true | 1 | 提升 100%~200% |
压测验证要点：
1. 在 acks=all + min.insync.replicas=2 时，手动停掉一个 ISR 副本，观察生产者是否抛出 NotEnoughReplicasException。
2. 在 unclean.leader.election.enable=true 时，通过 kill -9 杀掉 leader，验证新 leader 是否丢失已确认消息。
3. 使用
1. 在 acks=all + min.insync.replicas=2 时，手动停掉一个 ISR 副本，观察生产者是否抛出 NotEnoughReplicasException。
2. 在 unclean.leader.election.enable=true 时，通过 kill -9 杀掉 leader，验证新 leader 是否丢失已确认消息。
3. 使用
kafka-producer-perf-test 工具分别测试三种 acks 模式下的 p99 延迟。
3.6 代码示例：生产者配置
// 最高可靠性配置示例
Properties props = new Properties();
props.put("bootstrap.servers", "broker1:9092,broker2:9092,broker3:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
// acks=all 确保所有 ISR 副本确认
props.put("acks", "all");
// 重试次数与幂等性配合
props.put("retries", Integer.MAX_VALUE);
props.put("enable.idempotence", true);
// 等待确认超时
props.put("request.timeout.ms", 30000);
KafkaProducer<String, String> producer = new KafkaProducer<>(props);
注意：当
enable.idempotence=true 时，Kafka 会自动将 acks 设置为 all，即使你显式指定为 0 或 1 也会被覆盖。在压测中需要区分幂等模式与非幂等模式下的 acks 行为差异。