Kafka生产者acks参数决定消息可靠性：acks=0发完即忘，acks=1仅Leader确认（默认），acks=all需ISR全部副本写入成功；搭配enable.idempotence=true、retries设大值及min.insync.replicas=2，并协同batch.size与linger.ms平衡吞吐与延迟。
acks 可选值及实际含义
生产者配置中 `acks` 参数只有三个合法取值，各自代表不同的一致性与性能权衡：
- acks=0：发完即忘。不等待任何 Broker 确认，吞吐最高，但网络丢包、Broker 崩溃或磁盘写失败时，消息必然丢失。
- acks=1（默认值）：只等 Leader 写入成功。Leader 收到并落盘即返回 ACK。若 Leader 在同步给 Follower 前宕机，且新选 Leader 没有该消息，就会丢失。
- acks=all（等价于 acks=-1）：必须等 ISR（In-Sync Replicas）中所有副本都写入成功才返回 ACK。这是强持久性保障，只要 ISR 中至少有一个副本存活，消息就不会丢。
高可靠场景下的推荐配置组合
单设 `acks=all` 不够，需配合其他参数才能真正落地可靠性：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
启用幂等性：
enable.idempotence=true。开启后自动将max.in.flight.requests.per.connection限制为 5，避免乱序重试导致重复；同时确保单分区“恰好一次”语义。 -
设置合理重试次数：
retries=2147483647（或明确设为较大值如 10），配合幂等性，让临时网络抖动或 Leader 切换可自动恢复。 -
服务端配合：Broker 端需设置
min.insync.replicas=2（至少 2 个副本同步才算成功），否则 `acks=all` 可能退化为 `acks=1`。
Java 示例配置片段
以下是最常用的安全生产配置（非低延迟场景）：
props.put("bootstrap.servers", "k1:9092,k2:9092,k3:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "all");
props.put("enable.idempotence", "true");
props.put("retries", "10");
props.put("batch.size", "16384");
props.put("linger.ms", "5");
别忽略 linger.ms 和 batch.size 的协同作用
`acks=all` 会增加单次请求延迟，而 `linger.ms` 和 `batch.size` 是对冲延迟的关键：
- `batch.size=16384`（16KB）让多条消息攒成一批发，降低网络请求频次；
- `linger.ms=5` 表示即使没攒够 16KB，也最多等 5ms 再发——在吞吐和延迟间取得平衡；
- 二者配合可显著提升单位时间发送量，尤其在中小消息体场景下效果明显。
