Kafka 的 ACK 机制是怎样的？
Kafka
消息队列
可靠性
分布式系统
什么是 ACK 机制？
ACK（Acknowledgment）机制是 Kafka 用来确保消息可靠性传输的一种机制。它允许生产者在消息发送后，等待来自 Broker 的确认响应，以此来保证消息已经被正确地接收和存储。
ACK 机制的三种级别
Kafka 提供了三种不同级别的 ACK 机制，可以根据业务需求在数据可靠性和性能之间做出权衡。
1. acks=0（无确认）
特点：
- 生产者发送消息后不等待任何确认
- 最高的吞吐量
- 可能丢失消息
- 适用于允许少量消息丢失的场景（如日志收集）
2. acks=1（Leader确认）
特点：
- 等待 Leader 副本确认
- 中等的吞吐量
- Leader 宕机时可能丢消息
- 常用于对可靠性要求中等的场景
3. acks=-1 或 all（全部确认）
特点：
- 等待所有 ISR 中的副本确认 特点：
- 等待所有 ISR 中的副本确认
- 最低的吞吐量
- 最高的可靠性保证
- 适用于对数据一致性要求较高的场景
配置示例
生产者配置
# ACK级别设置
acks=all # 或 acks=0, acks=1
ACK 机制的对比与使用场景
| 特性 | acks=0 | acks=1 | acks=all |
|---|---|---|---|
| 消息可靠性 | 低 | 中 | 高 |
| 响应延迟 | 最低 | 中等 | 最高 |
| 吞吐量 | 最高 | 中等 | 最低 |
| 是否会丢消息 | 可能丢失 | Leader宕机时可能丢失 | 不会丢失 |
| 适用场景 | 日志收集 监控数据 | 一般业务消息 实时分析 | 支付交易 核心业务 |
| CPU开销 | 最低 | 中等 | 最高 |
| 网络开销 | 最低 | 中等 | 最高 |
小结
Kafka 的 ACK 机制通过不同的确认级别，让用户可以根据业务需求在数据可靠性和性能之间做出选择。
相关推荐：