kafka 的ack机制

ACK 的三个可选配置值

在生产者配置中，通过 acks 参数进行设置（通常是 acks，而不是 ack）。

1. acks = 0

• 含义：“发后即忘”。生产者发送消息后，完全不需要等待来自 Kafka 服务器的任何确认，就立即认为消息发送成功。

• 优点：

  • 延迟最低：因为没有等待，吞吐量最高。

• 缺点：

  • 可靠性最差：如果网络抖动、Broker 宕机等，消息可能丢失，生产者却无从知晓。

• 适用场景：对可靠性要求极低，允许少量消息丢失，但追求极高吞吐量的场景，例如日志收集。

2. acks = 1

• 含义：默认值。生产者发送消息后，只需要等待分区的 领导者副本 将消息写入其本地日志，就可以认为发送成功。

• 优点：

  • 在可靠性、延迟和吞吐量之间取得了较好的平衡。

• 缺点：

  • 仍有丢失风险：如果领导者副本刚写入消息就突然宕机，且消息还未被其他追随者副本同步，那么新的领导者会被选举出来，但它不包含这条消息，导致消息丢失。

• 适用场景：大多数常规业务场景，对可靠性有一定要求，但可以接受在极端情况下的少量丢失。

3. acks = all (也可以写作 acks = -1)

• 含义：最严格。生产者发送消息后，需要等待分区的 所有同步中的副本（ISR） 都将消息成功写入其本地日志，才会收到成功确认。

• 优点：

  • 可靠性最高：只要至少有一个同步副本存活，消息就不会丢失。

• 缺点：

  • 延迟最高：因为需要等待所有副本的确认，网络往返时间更长。

  • 吞吐量最低。

• 额外配置：为了确保不陷入无限等待，通常需要配合 min.insync.replicas 参数（通常在 Broker 或主题级别配置）使用。

  • min.insync.replicas=2 表示至少需要 2个 ISR 副本确认，生产者才认为成功。如果 ISR 集合中的副本数少于这个值，生产者会抛出一个异常（NotEnoughReplicasException）。