通过 Apache Kafka 中的死信队列进行错误处理( 三 ) _Kafka

【通过 Apache Kafka 中的死信队列进行错误处理】

文章插图
Parallel Consumer 客户端具有强大的重试逻辑。这包括可配置的延迟和动态错误或处理。错误也可以发送到死信队列。
使用死信队列中的消息
将错误发送到死信队列后，您还没有完成！坏消息需要被处理或至少被监控！
死信队列是从事件处理中带外处理数据错误处理的绝佳方式，这意味着错误处理程序可以与事件处理代码分开创建或演变。
存在大量使用死信队列的错误处理策略。DO 和 DONT 探索最佳实践和经验教训。
错误处理策略
有几个选项可用于处理存储在死信队列中的消息：

重新处理：DLQ中的一些消息需要重新处理。但是，首先，需要解决这个问题。解决方案可以是自动脚本、编辑消息的人工交互，或向生产者返回错误，要求重新发送（更正的）消息。
删除错误消息（经过进一步分析）：根据您的设置，可能会出现错误消息。但是，在删除它们之前，业务流程应该检查它们。例如，仪表板应用程序可以使用错误消息并将它们可视化。
高级分析：另一种选择是分析传入数据以获取实时洞察或问题，而不是处理 DLQ 中的每条消息。例如，一个简单的 ksqlDB 应用程序可以应用流处理进行计算，例如每小时错误消息的平均数量或任何其他有助于确定 Kafka 应用程序中的错误的见解。
停止工作流：如果很少会出现坏消息，结果可能是停止整个业务流程。该动作可以是自动的，也可以由人决定。当然，停止工作流也可以在抛出错误的 Kafka 应用程序中完成。如果需要，DLQ 将问题和决策外部化。
忽略：这听起来可能是最糟糕的选择。只是让死信队列填满，什么都不做。然而，即使这样在某些用例中也很好，比如监控 Kafka 应用程序的整体行为。请记住，Kafka 主题具有保留时间，并且在该时间之后从主题中删除消息。只需为您设置正确的方式即可。并监控 DQL 主题是否存在意外行为（例如填充太快）。

Apache Kafka 中死信队列的最佳实践
以下是在 Kafka 应用程序中使用死信队列进行错误处理的一些最佳实践和经验教训：

定义处理无效消息的业务流程（自动与人工）
- 现实：通常，根本没有人处理 DLQ 消息
- 备选方案 1：数据所有者需要接收警报，而不仅仅是基础架构团队
- 备选方案 2：警报应通知记录团队系统数据错误，他们将需要从记录系统重新发送/修复数据。
- 如果没有人关心或抱怨，请考虑质疑和审查 DLQ 存在的必要性。相反，这些消息也可以在初始 Kafka 应用程序中被忽略。这节省了大量的网络负载、基础设施和资金。
构建带有适当警报的仪表板并整合相关团队（例如，通过电子邮件或 Slack 警报）
定义每个 Kafka 主题的错误处理优先级（停止、删除和重新处理）
仅将不可重试的错误消息推送到 DLQ - 连接问题是消费者应用程序的责任。
保留原始消息并将它们存储在 DLQ 中（带有额外的标头，例如错误消息、错误时间、发生错误的应用程序名称等）——这使得重新处理和故障排除变得更加容易。
想想你需要多少 Dead Letter Queue Kafka 主题。总是有取舍。但是将所有错误存储在单个 DLQ 中可能对进一步分析和重新处理没有意义。