5.2. 数据持久性


消息发送确认可最大程度降低消息丢失的可能性。默认情况下,将 acks 属性设置为 acks=all 时启用确认。要控制制作者从代理等待确认的时间,并处理发送消息的潜在延迟,您可以使用 delivery.timeout.ms 属性。

确认消息发送

# ...
acks=all 
1

delivery.timeout.ms=120000 
2

# ...
Copy to Clipboard Toggle word wrap

1
acks=all 强制领导副本将消息复制到特定数量的后续人员,然后再确认消息请求被成功收到。
2
等待完整发送请求的最长时间(毫秒)。您可以将值设为 MAX_LONG,以委派给 Kafka 的重试次数。默认值为 120000 或 2 分钟。

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

使用 acks=all 时,领导机会等待所有同步副本确认消息发送。主题的 min.insync.replicas 配置设定了同步副本确认所需的最小所需数量。确认数量包括领导和跟着者的数量。

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

  • 制作者配置:

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

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

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

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

下表描述了此配置的工作方式,具体取决于复制领导副本的后续者可用性。

Expand
表 5.1. 遵循可用性
可用和同步的后续者数量致谢生产者可以发送消息?

2

领导等待 2 个后续确认

1

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

0

领导机引发异常

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

注意

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

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat