我目前正在使用 AWS 基础设施实施我的第一个 Web 应用程序并学习基础知识。我遇到了一个设计问题，所以想出了以下场景来说明我的问题：
假设我正在制作一个 Web 应用程序，将网站保存/打印为 pdf 并将其存储在 S3 上。前端有一个单一的形式。用户将输入他们想要保存为 pdf 的站点的 url，然后单击提交。该应用程序应将给定 url 处的页面打印为 pdf 并将文件呈现给用户。
为了使应用程序具有可扩展性，我想象单击提交会将 SQS 消息发送到带有要处理的 url 的队列。然后，一群工人可以从这个队列中消费，创建 pdf 并将它们存储在 S3 中，然后将 S3 密钥/路径存储到 SimpleDB。我遇到的问题是工作人员如何通知网络应用程序处理完成？
示例设计：
我想 Web App 可以不断轮询 SimpleDB，直到出现 S3 密钥的条目，但是这个解决方案似乎有点笨拙。我觉得这是一个必须经常遇到的模式/问题。谁能提供一种通用的方法来解决这个问题？
此外，云中常见设计模式的任何推荐资源都将非常有益。
除非您使用 WebSockets 之类的东西，否则我认为这不是问题。当用户发出请求时，Web 应用程序将轮询 SimpleDB（就像您提到的那样）以检查处理是否完成（或者是否有错误）。使用 WebSockets 之类的东西，您可以拥有另一个队列，Web 应用程序将订阅该队列，以便在处理完成时收到通知，然后通知浏览器它已完成。
正如您所说，您基本上已经解决了除了前端之外的所有问题，前端需要轮询我们的后端 API 以查看媒体是否准备好。在我的公司，我们按照你上面说的做，渲染网页截图，也做 PDF 的 jpg 快照，办公文档，处理编码视频和音频。
我们使用 ajax 进行更新，并将它们设置为每秒 ping 几次，然后逐渐回退到每秒一次，每隔几秒一次，以免对我们的服务器造成太大压力。正如另一个答案所提到的，另一个选项是使用 websockets，它是与服务器的持久连接，您可以从中“推送”和“拉取”数据。不过，大多数人都使用 ajax 轮询方法。对于像 Apache 这样的旧技术，这对于数千个连接来说可能是个大问题，但对于像 Nginx、Node 和中间缓存这样的东西来说，这并不是什么大问题。
您可以将对象（如标记）存储在 S3 中，然后轮询 S3 而不是简单的 DB。这样你就可以避免给你的 SimpleDB 带来压力，你的轮询性能会更稳定。
您可以使用这种方法从您的 Web 应用程序实例进行轮询，甚至从 ajax 层进行轮询。（尽管后者不是最佳选择，因为这些调用中的任何错误都不会记录在您的服务器中）