5.2. 数据持久性
消息发送致谢可最大程度降低消息丢失的可能性。默认情况下,使用 acks=all 设置的 acks 属性启用确认。
致谢消息发送
# ...
acks=all
# ...
- 1
- 在确认成功收到消息请求之前,
acks=all会强制领导副本将消息复制到一定数量的后续者中。
acks=all 设置提供最强的保证交付,但这会增加制作者发送消息和接收被确认的发送方之间的延迟。如果您不要求这种强保证,则 acks=0 或 acks=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 的多节点部署。
下表描述了此配置的运作方式,具体取决于复制领导副本的后续人员的可用性。
| 和 in-sync 的后续机构数量 | 致谢 | 制作者可以发送消息? |
|---|---|---|
| 2 | 领导人等待 2 跟进者确认 | 是 |
| 1 | 领导等待 1 个跟随者的确认 | 是 |
| 0 | 领导人引发异常 | 否 |
主题复制因素 3 创建一个领导副本,以及两个后续者。在此配置中,如果单个后续程序不可用,则制作者可以继续。有些延迟可能会在从同步副本中删除失败的代理或创建新领导时发生。如果第二个后续程序也不可用,则消息发送将无法成功。领导人不会将错误(并非足够副本)发送到生产者,而不是确认成功消息交付。制作者引发同等异常。通过 重试 配置,生产者可以重新发送失败的消息请求。
如果系统失败,则缓冲区中未发送数据的风险会丢失。