Lambda执行中断时如何恢复Kinesis数据并避免重复写入？

可以实现断点续抓，但Kinesis Firehose本身不提供已写入数据的查询能力，无法直接通过它判断哪些分块已经成功写入。需要通过额外的状态管理和幂等性设计来实现需求，具体方案如下：

1. 核心思路：维护独立的抓取进度状态 #

因为Firehose是为批量落地S3设计的缓冲服务，没有暴露数据查询/回溯的API，所以必须自行记录抓取的断点信息：

• 用DynamoDB存储每个抓取任务的进度：
  • 存储字段示例：任务唯一ID（可复用CloudWatch Event的ID）、最后成功抓取的分页标记（比如第三方API返回的next_token）、已成功写入Firehose的分块序号列表、任务状态（运行中/失败/完成）。
  • Lambda启动时，先查询DynamoDB获取当前任务的断点，直接从该位置开始后续的分块抓取，而非从头开始。

2. 幂等性保障：避免重复写入 #

即使Lambda重试时出现重复抓取的情况，也要保证数据不会重复落地：

• 给每个分块数据添加唯一业务标识（比如任务ID_分块序号），将其作为数据的一部分写入Firehose。
• 数据落地到S3后，下游处理环节（比如ETL任务）可以通过这个唯一标识做去重；或者在写入Firehose前，先查询DynamoDB确认该分块是否已经成功写入，避免重复提交。

3. 重试与触发逻辑优化 #

• 依赖CloudWatch Event Bridge的默认重试可能无法满足断点续抓需求，建议用Step Functions编排整个抓取流程：
  • 将每个分块的抓取、写入Firehose、更新状态拆分为独立步骤，Step Functions会自动维护流程状态，失败时可配置精准的重试策略（比如重试间隔、次数），重启后直接从失败的步骤继续执行。
  • 如果坚持用Lambda+Event Bridge，可在Lambda失败时更新DynamoDB的错误状态，再通过CloudWatch Alarm监听Lambda失败指标，触发新的Event Bridge事件，让Lambda从断点重新执行。

4. 替代方案：切换为Kinesis Data Streams #

如果一定要通过Kinesis服务本身回溯已写入数据，可将Firehose替换为Kinesis Data Streams：

• Data Streams提供GetRecords等API，可以读取流中已写入的记录，Lambda重启后可以读取流的最后一条记录，提取分块标记来恢复抓取进度。
• 之后可以再通过Firehose将Data Streams的数据落地到S3，兼顾流的可回溯性和S3的批量存储能力。

内容的提问来源于stack exchange，提问作者coderman