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

Question

根据AWS 文档：

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

根据AWS 文档的另一页：

Kinesis 客户端库 (KCL) 依靠您的 processRecords 代码来处理因处理数据记录而产生的任何异常。从 processRecords 抛出的任何异常都会被 KCL 吸收。为避免对重复出现的故障进行无限重试，KCL 不会重新发送发生异常时处理的记录批次。然后 KCL 为下一批数据记录调用 processRecords，而无需重新启动记录处理器。这有效地导致消费者应用程序观察到跳过的记录。为防止跳过记录，请适当处理 processRecords 中的所有异常。

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

Answer 1

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

首先介绍一下背景：

• KCL 记录处理旨在从多个主机运行。假设您有 3 个主机和 12 个要处理的分片 - 每个主机运行一个工作程序，并将拥有 4 个分片的处理权。
• 如果在处理这些分片之一的过程中抛出异常，KCL 将吸收异常并将其视为所有记录都已处理 - 有效地“跳过”任何未处理的记录。
  • 请记住，这是您抛出异常的代码，因此您可以在它转义到 KCL 之前处理它
• 当 KCL 工作器本身出现故障/停止时，这些分片将转移到另一个工作器。例如，如果您缩小到两个主机，则由第三个工作器工作的 4 个分片将转移到另外两个。

第一条语句试图（不是很清楚）说明当KCL 任务失败时，该工作程序实例将保持对其正在处理的分片的控制（而不是将它们转移给另一个工作程序）。