Apache Kafka 成为许多企业架构最喜好的集成中间件。纵然对付云优先计策，企业也可以利用 Kafka 的数据流作为云原生集成平台即做事 (iPaaS)。
Apache Kafka 数据流中的行列步队模式在我开始这篇文章之前，我想让你知道这个内容是关于“JMS、行列步队和 Apache Kafka”的博客系列的一部分：
去世信行列步队 (DLQ)是系统或数据流平台内的一种做事实现，用于存储未成功处理的。系统不是被动地转储，而是将其移动到去世信行列步队。
企业集成模式 (EIP)改为调用设计模式去世信通道。我们可以将两者用作同义词。
本文重点先容数据流平台 Apache Kafka。在 Kafka 中将放入 DLQ 的紧张缘故原由常日是格式缺点或内容无效/缺失落。例如，如果预期值是整数，但生产者发送了字符串，则会发生运用程序缺点。在更动态的环境中，“主题不存在”非常可能是无法通报的另一个缺点。
因此，常日不要利用现有中间件履历中的知识。Message Queue 中间件（如符合 JMS 的 IBM MQ、TIBCO EMS 或 RabbitMQ）与分布式提交日志（如 Kafka）的事情办法不同。由于许多其他缘故原由，行列步队中的 DLQ 用于行列步队系统，这些缘故原由不能一对一地映射到 Kafka。例如，MQ 系统中的由于每条的 TTL（生存韶光）而过期。
因此，在 Kafka 中将放入 DLQ 的紧张缘故原由是格式缺点或内容无效/缺失落。
Apache Kafka 中去世信行列步队的替代方案Kafka 中的去世信行列步队是一个或多个 Kafka 主题，它们吸收和存储由于缺点而无法在另一个流管道中处理的。此观点许可利用以下传入连续流，而不会由于无效的缺点而停滞事情流。
Kafka Broker 很笨——智能端点供应缺点处理Kafka 架构不支持 broker r 中的DLQ。故意地，Kafka 建立在与当代微做事相同的原则上，利用“哑管道和智能端点”原则。这便是为什么与传统代理比较，Kafka 的扩展性如此之好。过滤和缺点处理发生在客户端运用程序中。
数据流平台的真正解耦可以实现更干净的领域驱动设计。每个微做事或运用程序都通过自己选择的技能、通信范式和缺点处理来实现其逻辑。
在传统的中间件和行列步队中，代理供应了这种逻辑。结果是域中的可扩展性和灵巧性较差，由于只有中间件团队才能实现集成逻辑。
用任何编程措辞自定义实现 Kafka 去世信行列步队Kafka 中的去世信行列步队独立于您利用的框架。一些组件为缺点处理和去世信行列步队供应了开箱即用的功能。但是，利用Java、Go、C++、Python 等任何编程措辞为 Kafka 运用程序编写去世信行列步队逻辑也很随意马虎。
去世信行列步队实现的源代码包含一个 try-catch 块来处理预期或意外非常。如果没有发生缺点，则处理该。如果发生任何非常，请将发送到专用的 DLQ Kafka 主题。
失落败缘故原由应添加到 Kafka 的标头中。不应变动键和值，以便将来对历史事宜进行重新处理和故障剖析。
去世信行列步队的开箱即用 Kafka 实现你并不总是须要实现你的去世信行列步队。许多组件和框架已经供应了它们的 DLQ 实现。
利用您自己的运用程序，您常日可以掌握缺点或在涌现缺点时修复代码。但是，与 3rd 方运用程序的集成并不一定许可您处理可能跨集成障碍引入的缺点。因此，DLQ 变得更加主要，并被包含在某些框架中。
Kafka Connect 内置去世信行列步队Kafka Connect 是 Kafka 的集成框架。它包含在开源 Kafka 下载中。不须要其他依赖项（除了您支配到 Connect 集群中的连接器本身）。
默认情形下，如果由于利用无效而发生缺点（例如利用缺点的 JSON 转换器而不是精确的 AVRO 转换器时），Kafka Connect 任务将停滞。删除无效是另一种选择。后者容忍缺点。
Kafka Connect 中 DLQ 的配置很大略。只需将两个配置选项 ' errors.tolerance' 和 ' errors.deadletterqueue.topic.name' 的值设置为精确的值：
博客文章“ Kafka Connect Deep Dive – 缺点处理和去世信行列步队”显示了利用 DLQ 的详细动手代码示例。
Kafka Connect 乃至可以用于处理 DLQ 中的缺点。只需支配另一个利用 te DLQ 主题的连接器。例如，如果您的运用程序处理 Avro 并且传入是 JSON 格式。然后连接器利用 JSON 并将其转换为 AVRO 以成功重新处理：
请把稳，Kafka Connect 没有用于源连接器的去世信行列步队。
Kafka Streams 运用程序中的缺点处理Kafka Streams 是 Kafka 的流处理库。它可与其他流式传输框架相媲美，例如 Apache Flink、Storm、Beam 和类似工具。但是，它是 Kafka 原生的。这意味着您可以在单个可扩展且可靠的根本架构中构建完全的端到端数据流。
如果您分别利用 Java（JVM 生态系统）来构建 Kafka 运用程序，建议险些总是利用 Kafka Streams 而不是 Kafka 的标准 Java 客户端。为什么？
Kafka Streams“只是”一个环绕常规 Java 生产者和消费者 API 的包装器，以及许多内置的附加功能。两者都只是嵌入到 Java 运用程序中的库（JAR 文件）。两者都是开源 Kafka 下载的一部分 - 没有额外的依赖项或容许证变动。许多问题已经开箱即用地办理，以构建成熟的流处理做事（流功能、有状态的嵌入式存储、滑动窗口、交互式查询、缺点处理等等）。Kafka Streams的内置功能之一是默认的反序列化非常处理程序。它许可您管理无法反序列化的记录非常。破坏的数据、禁绝确的序列化逻辑或未处理的记录类型都可能导致缺点。该功能不称为去世信行列步队，但开箱即用地办理了相同的问题。
Spring Kafka 和 Spring Cloud Stream 的缺点处理Spring 框架对 Apache Kafka 有很好的支持。它供应了许多模板以避免自己编写样板代码。Spring-Kafka 和 Spring Cloud Stream Kafka 支持各种重试和缺点处理选项，包括基于韶光/计数的重试、去世信行列步队等。
只管 Spring 框架功能非常丰富，但它有点重，并且有一个学习曲线。因此，它非常适宜新建项目，或者如果您已经将 Spring 用于其他场景的项目。
有很多很棒的博客文章展示了不同的示例和配置选项。还有用于去世信行列步队的官方 Spring Cloud Stream 示例。Spring 许可利用大略的注释构建逻辑，例如 DLQ。这种编程方法是一些开拓职员钟爱的范例，而另一些则不喜好它。只需理解选项并为自己选择得当的选项即可。
Apache Kafka 并行消费者的可扩展处理和缺点处理在许多客户对话中，事实证明，要求去世信行列步队的紧张缘故原由常日是处理连接到外部 Web 做事或数据库的失落败。超时或 Kafka 无法并行发送各种要求会导致某些运用程序瘫痪。这个问题有一个很好的办理方案：
Apache Kafka的并行消费者是Apache 2.0 容许下的开源项目。它供应了一个带有客户端行列步队的并行 Apache Kafka 客户端包装器、一个具有关键并发性的更大略的消费者/生产者 API，以及可扩展的非壅塞 IO处理。
该库许可您通过单个 Kafka Consumer 并行处理，这意味着您可以在不增加要处理的主题中的分区数量的情形下增加 Kafka Consumer 并行度。对付许多用例，这通过减少 Kafka 代理的负载来提高吞吐量和延迟。它还开辟了新的用例，例如极度并行性、外部数据丰富和排队。
一个关键特性是在单个 Kafka 消费者运用程序中处理/重复 Web 做事和数据库调用。并行化避免了一次发送单个 Web 要求的须要：
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 中可能对进一步剖析和重新处理没故意义。请记住，DLQ 会以有担保的顺序终止处理，并使任何类型的离线处理变得更加困难。因此，Kafka DQL 并不适宜每个用例。
何时不在 Kafka 中利用去世信行列步队？让我们磋商一下不应该将哪些类型的放入 Kafka 的去世信行列步队中：
DLQ 用于背压处理？由于大量的峰值而利用 DLQ 进行节流并不是一个好主张。Kafka 日志背后的存储会自动处理背压。消费者以它可以按自己的速率获取数据的办法提取数据（或者配置缺点）。如果可能的话，弹性地扩展消费者。纵然您的存储空间已满，DLQ 也无济于事。这是它的问题，与是否利用 DLQ 无关。连接失落败的DLQ？由于连接失落败而将放入 DQL 无济于事（纵然在多次重试之后）。以下也无法连接到该系统。您须要办理连接问题。可以根据须要存储在常规主题中（取决于保留韶光）。用于数据管理和缺点预防的模式注册表末了但同样主要的是，让我们磋商在某些情形下减少乃至肃清对去世信行列步队的需求的可能性。
卡夫卡的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 供应支持的事宜溯源：
新的基于异步事宜的架构中的一个关键寻衅是缺点处理。 Santander 利用重试和 DQL Kafka 主题构建的缺点处理办理了这些问题：
查看来自 Santander 的集成互助伙伴 Consdata的 Kafka 峰会演讲“基于重试策略和去世信主题的 Apache Kafka 中的可靠事宜通报”中的详细信息。
Apache Kafka 中可靠且可扩展的缺点处理缺点处理对付构建可靠的数据流管道和平台至关主要。存在不同的替代方案来办理这个问题。该办理方案包括去世信行列步队的自定义实现或利用正在利用的框架，例如 Kafka Streams、Kafka Connect、Spring 框架或 Kafka 的并行消费者。
优步、CrowdStrike 和桑坦德银行的案例研究表明，缺点处理并不总是很随意马虎实现。当您设计新的运用程序或架构时，须要从一开始就考虑到这一点。利用 Apache Kafka 进行实时数据流传输很有吸引力，但只有在您能够处理意外行为时才能成功。去世信行列步队是许多场景的绝佳选择。
