Amazon web services 浏览器轮询的AmazonSQS？

我想知道AWS SQS是否是进行浏览器轮询的正确服务

例如：

1） 用户通过浏览器访问应用程序，并请求生成大型PDF

2） API向用户回复“OK”，并将请求转发给SQS

3） SQS队列由lambda读取，lambda生成PDF并将其存储到S3

现在，在第2步和第3步之间的某个时刻，用户浏览器希望知道PDF何时完成（没有电子邮件），它可以通过轮询SQS以获得特定的消息ID来完成这一点（这可能吗？），但我有一些问题：

a） 用户和lambda从SQS读取相同的消息“可以”吗？那么太多的用户用轮询请求重载SQS又如何呢

b） 是否可以编辑/更新SQS消息？用户如何知道lambda完成了PDF并获得了下载链接？lambda是否可以编辑包含S3链接的消息？如果不是的话，在不浪费太多资源的情况下，建议用户使用什么方式/AWS服务来了解PDF何时完成

而且最好不需要数据库就可以了。。。我们确实没有太多的用户，但我们正在努力使事情变得正确，并证明未来

---

标记boto，因为我正在用Python做所有这些。。。最终。

您不想为此使用SQS-每次轮询最多只能读取10条消息，如果您的队列中有很多消息，您可能（将）在继续轮询时一遍又一遍地看到相同的消息，也就是说，无法保证您会看到所有消息。更不用说，您将进入可视性超时的地狱，并使多个客户端轮询您的队列

您的输出PDF将转到S3，因此您可以执行以下操作：让Lambda在步骤（2）中为输出PDF构造唯一的S3密钥，并在“OK”响应中将密钥发送回客户端。然后让客户端使用该键轮询输出bucket。当然，构建的PDF应该使用此键编写

---

要从浏览器进行轮询，请使用GetObject。您需要在输出存储桶上配置CORS，才能使其工作。

我建议使用Web套接字将通知推回到浏览器，而不是让浏览器轮询（即定期发送GetObject API调用）S3中的PDF文件。如果生成PDF时发生错误，此方法将帮助您通知浏览器

更多详情请看（6:40）

在10:27，您将发现一个与您试图实现的目标相匹配的图表（用S3替换DynamoDB组件）

通过比较S3定价[1]和Web套接字定价[2]，我还认为基于Websocket的方法比轮询方法更便宜。但您需要进行测试（反映生产工作负载）并对此进行验证

[1]

---

[2] 中的“WebSocket API”很有趣！所以可以在S3中“预注册”一个项目？你为S3服务的轮询付费吗？是的，我想这就像“预注册”。。。您只需选择一个以某种方式唯一的文件名（可能将客户端id与当前时间戳结合起来？）。轮询应该非常便宜，即使每个客户端每秒检查一次。。。我发现S3的响应速度非常快，可靠性也很高。我猜如果pdf在lambda中失败，就没有办法检查了？最好的情况是在客户端轮询上设置14分钟的超时（lambda执行超时）？如果它只是崩溃，那么您是对的，没有办法将此消息传达给您的客户端。但是也许你可以把你的函数包装成一个try-catch，让lambda写一个错误密钥，客户端可以轮询它。。。这肯定比轮询S3更可取