Kinesis 客户端库记录处理器故障
Kinesis client library record processor failure
根据AWS docs：
The worker invokes record processor methods using Java ExecutorService tasks. If a task fails, the worker retains control of the shard that the record processor was processing. The worker starts a new record processor task to process that shard. For more information, see Read Throttling.
根据 AWS 文档 another page：
The Kinesis Client Library (KCL) relies on your processRecords code to
handle any exceptions that arise from processing the data records. Any
exception thrown from processRecords is absorbed by the KCL. To avoid
infinite retries on a recurring failure, the KCL does not resend the
batch of records processed at the time of the exception. The KCL then
calls processRecords for the next batch of data records without
restarting the record processor. This effectively results in consumer
applications observing skipped records. To prevent skipped records,
handle all exceptions within processRecords appropriately.
这两个说法不是相互矛盾的吗？一个说记录处理器重新启动，另一个说碎片被跳过。
当记录处理器发生故障时，KCL 究竟做了什么？ KCL 工作人员如何知道记录处理器是否发生故障？
根据我编写、调试和支持基于 KCL 的应用程序的经验，第二个陈述更多的是 clear/accurate/useful 描述您应该如何考虑错误处理。
首先，一些背景知识：
- KCL 记录处理旨在 运行 来自多个主机。假设您有 3 个主机和 12 个分片要处理 - 每个主机 运行 是一个工人，并且将拥有 4 个分片的处理。
- 如果在处理其中一个分片期间抛出异常，KCL 将吸收该异常并将其视为所有记录都已处理 - 实际上 "skipping" 任何未处理的记录。
- 记住，这是您抛出异常的代码，因此您可以在它逃逸到 KCL 之前处理它
- 当 KCL worker 本身 fails/is 停止时，这些分片将转移给另一个 worker。例如，如果您缩小到两个主机，则第三个工作人员正在处理的 4 个分片将转移到另外两个。
第一个陈述试图（不是很清楚）说 当 一个 KCL 任务失败时，worker 的 instance控制它正在处理的分片（而不是将它们转移给另一个工作人员）。
根据AWS docs：
The worker invokes record processor methods using Java ExecutorService tasks. If a task fails, the worker retains control of the shard that the record processor was processing. The worker starts a new record processor task to process that shard. For more information, see Read Throttling.
根据 AWS 文档 another page：
The Kinesis Client Library (KCL) relies on your processRecords code to handle any exceptions that arise from processing the data records. Any exception thrown from processRecords is absorbed by the KCL. To avoid infinite retries on a recurring failure, the KCL does not resend the batch of records processed at the time of the exception. The KCL then calls processRecords for the next batch of data records without restarting the record processor. This effectively results in consumer applications observing skipped records. To prevent skipped records, handle all exceptions within processRecords appropriately.
这两个说法不是相互矛盾的吗？一个说记录处理器重新启动，另一个说碎片被跳过。 当记录处理器发生故障时，KCL 究竟做了什么？ KCL 工作人员如何知道记录处理器是否发生故障？
根据我编写、调试和支持基于 KCL 的应用程序的经验，第二个陈述更多的是 clear/accurate/useful 描述您应该如何考虑错误处理。
首先，一些背景知识：
- KCL 记录处理旨在 运行 来自多个主机。假设您有 3 个主机和 12 个分片要处理 - 每个主机 运行 是一个工人，并且将拥有 4 个分片的处理。
- 如果在处理其中一个分片期间抛出异常，KCL 将吸收该异常并将其视为所有记录都已处理 - 实际上 "skipping" 任何未处理的记录。
- 记住，这是您抛出异常的代码，因此您可以在它逃逸到 KCL 之前处理它
- 当 KCL worker 本身 fails/is 停止时，这些分片将转移给另一个 worker。例如，如果您缩小到两个主机，则第三个工作人员正在处理的 4 个分片将转移到另外两个。
第一个陈述试图（不是很清楚）说 当 一个 KCL 任务失败时，worker 的 instance控制它正在处理的分片（而不是将它们转移给另一个工作人员）。