【问题标题】:Kafka Streams Retry PAPI and dead letterKafka Streams 重试 PAPI 和死信
【发布时间】:2020-05-26 20:48:46
【问题描述】:

我正在尝试在 kafka 流处理器拓扑中实现重试逻辑,以防接收器主题产生异常。

  1. 我正在使用自定义 ProductionExceptionHandler 以便能够在 context.forward 上将“producer.send”上发生的异常捕获到接收器主题

  2. 如果向原始接收器主题发送异常,我应该使用什么标准才能将消息重新发送到备用接收器主题。这是否可以从生产者异常处理程序中的异常类型推断出来,而不会损害 Kafka 流中内部生产者的事务性质。

  3. 如果我们决定在某些不可恢复的错误中从生产异常处理程序生成死信队列,这是否可以在“EOS”保证的上下文中完成,或者它必须是拓扑未知的自定义生产者.

【问题讨论】:

    标签: apache-kafka apache-kafka-streams


    【解决方案1】:

    Kafka Streams 没有内置对死信队列的支持。因此,您需要“靠自己”来实现它。

    如果向原始接收器主题发送异常,我应该使用什么标准才能将消息重新发送到备用接收器主题。

    不确定您的意思是什么?能详细点吗?

    这可以从生产者异常处理程序中的异常类型推断出来

    也不确定这部分。

    不损害 Kafka 流中内部生产者的事务性质。

    这是不可能的。您无权访问内部生产者。

    如果我们决定在某些不可恢复的错误中从生产异常处理程序生成死信队列,这是否可以在“EOS”保证的上下文中完成,或者它必须是拓扑未知的自定义生产者。

    您需要维护自己的生产者,因此它超出了 EOS 的范围。

    【讨论】:

    • 感谢马蒂亚斯的回复。我一直在寻找 kafka 流中的某种自我修复功能,以防由于未满足最低 ISR 条件等而导致偶尔的生产异常。有没有一种方法可以在领导者/追随者尝试时至少暂停特定的流任务整理复制滞后。如果生产异常冒泡,最终会导致重新平衡或流被关闭,这两者都不能真正解决与 ISR 相关或其他网络相关的问题。 max.block.ms 是唯一的选择吗?
    • Atm,您只能为底层消费者/生产者配置“无限”超时/重试,以防止线程死亡。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-01-06
    • 2017-06-09
    • 2021-05-04
    • 2018-04-02
    • 1970-01-01
    • 2021-09-06
    • 2019-03-30
    相关资源
    最近更新 更多