Kinesis 客户端库记录处理器故障

Question

根据AWS docs：

worker 使用 Java ExecutorService 任务调用记录处理器方法。如果任务失败，工作人员将保留对记录处理器正在处理的分片的控制权。工作人员启动一个新的记录处理器任务来处理该分片。有关详细信息，请参阅读取限制。

根据 AWS 文档上的 another page：

Kinesis 客户端库 (KCL) 依赖于您的 processRecords 代码 处理因处理数据记录而产生的任何异常。任何 从 processRecords 抛出的异常被 KCL 吸收。避免 重复失败时无限重试，KCL 不会重新发送 在异常发生时处理的一批记录。当时的KCL 为下一批数据记录调用 processRecords 重新启动记录处理器。这有效地导致消费者 应用程序观察跳过的记录。为了防止跳过记录， 适当处理 processRecords 中的所有异常。

这两种说法不是相互矛盾的吗？一个说记录处理器重新启动，另一个说分片被跳过。 当记录处理器发生故障时，KCL 究竟做了什么？ KCL 工作人员如何知道记录处理器是否发生故障？

Answer 1

根据我编写、调试和支持基于 KCL 的应用程序的经验，第二个语句更清晰/准确/有用，用于描述您应该如何考虑错误处理。

首先，有一点背景：

• KCL 记录处理设计为从多个主机运行。假设您有 3 个主机和 12 个分片要处理 - 每个主机运行一个工作程序，并且将拥有 4 个分片的处理。
• 如果在处理其中一个分片期间引发异常，KCL 将吸收异常并将其视为所有记录都已处理 - 有效地“跳过”任何未处理的记录。
  • 请记住，这是您引发异常的代码，因此您可以在它逃逸到 KCL 之前对其进行处理
• 当 KCL 工作程序本身失败/停止时，这些分片将转移到另一个工作程序。例如，如果您缩减为两台主机，则第三台工作人员正在处理的 4 个分片将转移到另外两个。

第一个语句试图（不是很清楚）说当一个 KCL 任务失败时，instance worker 将保持对它正在处理的分片的控制（而不是将它们转移给其他工人）。