上下文: 我有一个由 6 个 lambda 函数(链接在一起)组成的管道，由 SNS 通知触发，每当文件登陆 S3 时就会生成该通知。这个管道本质上是获取文件(几 GB)，过滤它(创建 Spark 集群来运行作业，然后在最后删除)，并将它插入到数据库中。 Lambda 正在编排流程。
问题: 如果一个 Lambda 出现故障，链条就会断开，因此无法进行有效的故障处理。其次，如果轮询/计算时间超过 5 分钟，我们会遇到超时，因此没有有效的重试。如果 lambda 失败，测试/调试问题需要很长时间。也没有可见性，例如有多少工作失败了，有多少通过了？我们不知道。在电子邮件上获取一堆 SNS 通知不是很有效/有帮助。如果链断裂，我们将无法执行清理操作，例如删除 SPark 集群或内务处理步骤。
我的问题: AWS Step Functions 是解决上述问题的好选择吗？您什么时候不使用 Step Function 服务？如果您无法通过 SNS 调用 Step Function，那么每当文件登陆 S3 时调用它的最佳方式是什么？欢迎分享任何其他方法来轻松有效地解决这个用例。
最佳答案
是的。您可以在 Step Function 中定义 catch 处理程序来处理失败的 lambda 并重新运行它们，或者在失败时执行任何您需要的操作。
这是一个从文件上传到 S3 触发 Step Functions 的示例:https://aws.amazon.com/blogs/compute/synchronizing-amazon-s3-buckets-using-aws-step-functions/
就是说，如果您只需要一个简单的重试逻辑，那么使用 SQS 或许可以更快地达到目标。当 SQS 客户端从队列中收到消息时，它们实际上并没有立即被删除，而是 SQS 暂停了消息。如果客户端在一定时间内没有删除消息，则这些消息将放回队列中。
遗憾的是，目前无法直接从 SQS 触发 lambda，但您可以设置一个或多个 CloudWatch 事件以定期轮询 SQS。
关于amazon-web-services - 使用 AWS Lambda 链的挑战，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49724655/