当前位置：首页 > news >正文

kafka 发送消息有哪些模式？各自的应用场景是什么？

news 2025/8/19 6:02:08

Kafka 生产者发送消息主要有三种模式，这些模式的核心区别在于对消息成功发送的确认程度，这直接影响到消息的可靠性、吞吞吐量和延迟。这三种模式由生产者的 acks 参数控制。

以下是这三种模式的详细说明及其应用场景：

这种模式也被称为“最多一次”投递（At Most Once）。

配置: acks=0
工作方式: 生产者将消息发送出去后，不会等待来自 Broker 的任何确认响应。它不关心消息是否被 Broker 成功接收，也不会进行任何重试。
优点:
- 延迟最低: 因为不需要等待网络往返的确认信息。
- 吞吐量最高: 生产者可以以网络允许的最快速度发送消息。
缺点:
- 可靠性最低: 消息有丢失的风险。如果 Broker 在接收到消息时宕机，或者网络出现瞬时故障，这条消息就永远丢失了。
应用场景:
- 可以容忍少量数据丢失的场景: 例如，日志收集、指标监控、用户行为追踪等。在这些场景下，丢失个别数据点对整体分析影响不大。
- 对性能和吞吐量要求极高，而对可靠性要求相对较低的场景。

这种模式提供了“至少一次”投递（At Least Once）的保证。

配置: acks=1 (这是默认配置)
工作方式: 生产者发送消息后，会等待分区的 Leader 副本成功将消息写入其本地日志后返回确认。只要收到了 Leader 的确认，生产者就认为消息发送成功了。
优点:
- 可靠性较高: 相比 acks=0，这种模式确保了消息至少被 Leader 副本接收。
- 性能和可靠性的良好平衡: 它在延迟和吞吐量方面表现适中。
缺点:
- 仍有较低的数据丢失风险: 如果 Leader 副本成功写入消息并向生产者发送确认后，但在 Follower 副本同步数据之前，Leader 宕机了，那么这条消息就会丢失。当新的 Leader 被选举出来后，它并没有这条消息。
应用场景:
- 大多数常规业务场景: 这是最常用的一种模式，适用于绝大多数要求消息可靠传输，但能容忍极小概率数据丢失的场景。例如，常规的业务消息通知、非核心业务的数据传递等。
- 对延迟有一定要求，但又不能完全忽略可靠性的场景。

这种模式提供了最强的“至少一次”投递（At Least Once）保证，也是实现“精确一次”（Exactly Once）语义的基础。

配置: acks=all (或 acks=-1)
工作方式: 生产者发送消息后，不仅需要等待 Leader 副本成功写入消息，还需要等待 ISR (In-Sync Replicas, 同步副本列表) 中所有的 Follower 副本都成功同步这条消息后，才会收到 Broker 的确认。
优点:
- 可靠性最高: 只要 ISR 中至少还有一个副本存活，消息就不会丢失，提供了最强的数据持久性保证。
缺点:
- 延迟最高: 因为需要等待多个 Broker 的确认，网络往返时间更长。
- 吞吐量较低: 等待确认的过程会降低发送速率。
应用场景:
- 对数据完整性和可靠性要求极高的场景: 绝对不能容忍任何数据丢失。
- 核心金融业务: 如交易、支付、订单处理等。
- 关键业务数据处理: 如计费、结算等。

模式	`acks` 配置	可靠性	延迟	吞吐量	适用场景
发后即忘	`acks=0`	最低	最低	最高	日志收集、监控指标、用户行为分析
同步发送	`acks=1` (默认)	较高	适中	适中	大部分常规业务场景，如消息通知
异步完全确认	`acks=all` / `-1`	最高	最高	最低	金融交易、核心订单系统、支付结算