我正在尝试创建一个使用dynamoDB表中的流的lambda函数。但是,我想知道哪种最佳做法是处理在执行过程中可能因某些错误而未处理的数据?例如,我的lambda失败了,我流了很多,这是重新处理丢失的数据的最佳方法吗?
谢谢
答案 0 :(得分:1)
为您处理。像Kinesis Streams一样,DynamoDB Streams将重新发送记录,直到成功处理它们为止。当您使用Lambda处理流时,这意味着成功退出该函数。如果出现错误并且函数意外退出,则DynamoDB流将仅重新发送正在处理的记录。
好处是,您可以保证至少一次处理,但是,需要注意一些事项。与Kinesis Streams一样,DynamoDB Streams可以按顺序处理记录。这样做的副作用是,当记录无法处理时,将对其进行重试,直到成功处理该记录或该记录在流中(可能是几天) 在流中处理其后的记录之前过期。< / p>
如何解决此问题取决于应用程序的需求。如果您需要至少一次处理但又不保证所有记录都按顺序处理,那么我只需将记录放入SQS队列中,然后从队列中进行处理即可。 SQS队列还将重试未成功处理的记录,但是与DynamoDB和Kinesis Streams不同,记录不会在队列中互相阻塞。如果在将记录从DynamoDB流传输到SQS队列时遇到错误,则可以重试,这可能会在SQS队列中引入重复项。
如果顺序很关键或不允许重复,则可以使用SQS FIFO队列。 SQS FIFO队列与(标准)SQS队列相似,不同之处在于,它们保证可以按顺序将消息传递给使用者,并具有重复数据删除窗口(5分钟),该窗口中添加到队列中的所有重复项都将被丢弃。
在这两种情况下,当使用SQS队列处理消息时,您都可以设置一个死信队列,如果消息无法处理N次,则可以自动发送该消息。
TLDR:使用SQS队列。
答案 1 :(得分:1)
由于所有现有答案均已过时,因此正在更新此线程。
AWS Lambda now supports the DLQs for synchronous steam read from DynamoDB表流。
在上下文中具有此功能,这是我建议的流程:
ProTip:您可以使用属性“在函数错误时Bisect”启用批量拆分。使用此选项,lambda可以缩小受影响的记录的范围。
答案 2 :(得分:0)
DynamoDB Streams会为每个事件调用Lambda函数,直到成功处理它为止(直到代码调用成功回调为止)。
在执行过程中出现错误时,您需要用代码来处理它,除非Lambda不会继续处理流中的其余消息。
如果由于错误而需要单独处理消息,则可以使用死信队列(通过Amazon SQS)来推送消息并继续处理流中的其余项目。您可以使用单独的逻辑来处理此队列中的消息。