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

用于数据治理和错误预防的模式注册表
最后但同样重要的是，让我们探讨在某些情况下减少甚至消除对死信队列的需求的可能性。
卡夫卡的Schema Registry是一种确保数据清理以防止生产者在负载中出错的方法。它在 Kafka 生产者中强制执行正确的消息结构：

文章插图
模式注册表是模式的客户端检查。Confluent Server 等一些实现在代理端提供了额外的模式检查，以拒绝来自未使用模式注册表的生产者的无效或恶意消息。
Kafka 死信队列的案例研究
让我们看看Uber、CrowdStrike 和 Santander Bank 的三个案例研究，它们在 Kafka 基础设施中实际部署死信队列。请记住，这些都是非常成熟的例子。不是每个项目都需要那么复杂。
Uber - 构建可靠的再处理和死信队列
在分布式系统中，重试是不可避免的。从网络错误到复制问题，甚至下游依赖关系的中断，大规模运行的服务必须准备好尽可能优雅地遇到、识别和处理故障。
鉴于 Uber 的运营范围和速度，它的系统必须具有容错能力，并且在智能失败时毫不妥协。Uber 将 Apache Kafka 用于各种极端规模的用例以实现这一目标。
利用这些特性，Uber 保险工程团队扩展了 Kafka 在其现有事件驱动架构中的作用，通过使用 n个阻塞请求重新处理和死信队列来实现解耦、可观察的错误处理，而不会中断实时流量。该策略有助于他们选择加入的驾驶员伤害保护计划在 200 多个城市可靠运行，并为注册驾驶员扣除每次行程的每英里保费。
这是 Uber 错误处理的示例。错误会降低重试主题的级别，直到登陆 DLQ：

文章插图
有关更多信息，请阅读 Uber 非常详细的技术文章：“使用 Apache Kafka 构建可靠的再处理和死信队列” 。
CrowdStrike - 处理数万亿事件的错误
CrowdStrike 是一家位于德克萨斯州奥斯汀的网络安全技术公司。它提供云工作负载和端点安全、威胁情报和网络攻击响应服务。
CrowdStrike 的基础设施每天使用 Apache Kafka 处理数万亿个事件。在我的“ Apache Kaka 网络安全博客系列”中，我介绍了以任何规模实时创建态势感知和威胁情报的相关用例。
CrowdStrike 定义了三个最佳实践来成功实现死信队列和错误处理：

在正确的系统中存储错误消息：定义基础设施和代码以捕获和检索死信。CrowdStrike 使用 S3 对象存储来存储潜在的大量错误消息。请注意，Kafka 的分层存储开箱即用地解决了这个问题，无需其他存储接口（例如，利用 Confluent Cloud 中的无限存储）。
使用自动化：放置工具以使修复万无一失，因为手动完成错误处理可能非常容易出错。
记录业务流程并聘请相关团队：标准化和记录流程以确保易于使用。并非所有工程师都熟悉组织处理死信消息的策略。

在像 CrowdStrike 这样的网络安全平台中，大规模实时数据处理至关重要。此要求也适用于错误处理。下一次网络攻击可能是故意包含不适当或无效内容的恶意消息（如 JavaScript 漏洞利用）。因此，必须通过死信队列实时处理错误。
桑坦德银行 - 用于重试和 DLQ 组合的邮箱 2.0
桑坦德银行在邮箱应用程序中处理海量数据的同步数据处理面临巨大挑战。他们重新架构了他们的基础架构并构建了一个解耦且可扩展的架构，称为“Santander Mailbox 2.0” 。
Santander 的工作负载并转移到由 Apache Kafka 提供支持的事件溯源：