从 Kafka 死信队列重试消息的最佳实践是什么

aru*_*upc 1 error-handling apache-kafka

我们使用 Kafka 作为微服务之间的消息传递系统。我们有一个 kafka 消费者收听特定主题,然后将数据发布到另一个主题中,由 Kafka 连接器接收,后者负责将其发布到某个数据存储中。

我们使用 Apache Avro 作为序列化机制。

我们需要启用 DLQ 来为 Kafka Consumer 和 Kafka Connector 添加容错。

由于多种原因,任何消息都可能移动到 DLQ:

  1. 格式错误
  2. 坏数据
  3. 对大量消息进行节流,因此某些消息可能会转移到 DLQ
  4. 由于连接,发布到数据存储失败。

对于上面的第 3 和第 4 点,我们想再次从 DLQ 重试消息。

同样的最佳实践是什么。请指教。

Sve*_*end 5

仅推送到导致不可重试错误的 DLQ 记录,即:示例中的点 1(格式错误)和点 2(错误数据)。对于 DLQ 记录的格式,一个好的方法是:

  • 将与原始记录值和密钥完全相同的 kafka 记录值和密钥推送到 DLQ,不要将其包裹在任何类型的信封中。这使得在故障排除期间使用其他工具重新处理变得更加容易(例如使用新版本的解串器等)。
  • 添加一堆Kafka标头来传达有关错误的元数据,一些典型的例子是:
    • 此记录的原始主题名称、分区、偏移量和 Kafka 时间戳
    • 异常或错误消息
    • 未能处理该记录的应用程序的名称和版本
    • 错误发生的时间

通常,我为每个服务或应用程序使用一个 DLQ 主题(不是每个入站主题一个,也不是跨服务共享的主题)。这往往会使事情保持独立和易于管理。

哦,您可能想对 DLQ 主题的入站流量进行一些监控和警报;)

恕我直言,第 3 点(高容量)应该处理某种自动缩放,而不是 DLQ。尝试总是高估(有点)输入主题的分区数,因为您可以启动服务的最大实例数受此限制。过多的消息不会使您的服务过载,因为 Kafka 消费者在他们决定时会明确轮询更多消息,因此他们永远不会要求超过应用程序处理能力的消息。如果出现消息高峰会发生什么,只是它们会继续堆积在上游 kafka 主题中。

第 4 点(连接)应该直接从源主题重试,不涉及任何 DLQ,因为错误是暂时的。将消息丢弃到 DLQ 并接收下一个消息不会解决任何问题,因为连接问题仍然存在,下一条消息也可能会被丢弃。读取或不读取来自 Kafka 的记录不会让它消失,因此存储在那里的记录稍后很容易再次读取。只有当它成功地将结果记录写入出站主题时,您才能对服务进行编程以前进到下一个入站记录(请参阅 Kafka 事务:读取主题实际上涉及写入 操作,因为新的消费者偏移量需要被持久化,所以你可以告诉你的程序持久化新的偏移量和输出记录作为同一个原子事务的一部分)。

Kafka 更像是一个存储系统(只有 2 个操作:顺序读取和顺序写入)而不是消息队列,它擅长持久性、数据复制、吞吐量、规模......(......和炒作;))。它往往非常适合将数据表示为一系列事件,如“事件源”。如果这个微服务设置的需求主要是异步点对点消息传递,并且如果大多数场景更喜欢超低延迟并选择丢弃消息而不是重新处理旧消息(正如列出的 4 点所建议的那样),也许像Redis队列这样的有损内存队列系统更合适吗?