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

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

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

1. 发后即忘 (Fire-and-Forget)

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

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

2. 同步发送 (Synchronous)

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

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

3. 异步发送 (Asynchronous with Full Acknowledgement)

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

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

总结与对比

选择哪种模式，完全取决于具体的业务需求。开发者需要在可靠性、性能（吞吐量和延迟）之间做出权衡，选择最适合当前应用场景的发送模式。