5.2. 数据持久性

邮件发送确认可最大程度降低消息丢失的可能性。默认情况下,使用 acks=all 设置的 acks 属性启用确认。

确认消息交付

# ...
acks=all 1
# ...

1
acks=all 强制领导副本将消息复制到特定数量的后续者,然后再确认成功收到消息请求。

acks=all 设置提供了最强的保证,但它会增加制作者发送消息和接收确认之间的延迟。如果您不要求此类强大的保证,则设置 acks=0acks=1 不提供交付保证,或者只确认领导副本已将记录写入其日志。

使用 acks=all 时,领导机会等待所有同步副本确认消息发送。主题的 min.insync.replicas 配置设置最低要求的 in-sync 副本确认数。确认次数包括领导和跟随者。

典型的起点是使用以下配置:

  • 制作者配置:

    • acks=all (默认)
  • 主题复制的代理配置:

    • default.replication.factor=3 (default = 1)
    • min.insync.replicas=2 (default = 1)

在创建主题时,您可以覆盖默认的复制因素。您还可以在主题配置中的主题级别覆盖 min.insync.replicas

AMQ Streams 在示例配置文件中使用此配置进行 Kafka 的多节点部署。

下表描述了此配置如何根据复制领导副本的遵循者来运行。

表 5.1. 跟随者的可用性

可用和同步的跟随者数量致谢制作者可以发送消息?

2

领导等待 2 个跟随者的确认

1

领导等待 1 个跟随者的确认

0

领导会引发异常

3 的主题复制因素会创建一个领导副本和两个后续者。在此配置中,如果单个后续者不可用,则制作者可以继续。有些延迟可能会使从同步副本中删除失败的代理或创建新领导。如果第二个后续程序也不可用,消息发送将无法成功。领导机向生产者发送错误(不是足够副本),而不是确认成功发送的消息。生产者引发一个对等的异常。使用 重试 配置时,生产者可以重新发送失败的消息请求。

注意

如果系统失败,则缓冲区中不会丢失数据的风险。