架构设计:web层如何知道工作层何时完成处理？

Question

我正在使用Amazon AWS构建一个用于教育目的的小型应用程序。Web应用程序有两个部分：

< li >用于上传图像的表单。 < li >显示上传图像的所有缩略图的网格。

1. 用户打开网页
2. 用户选择要上载的图像
3. 向web层发送AJAX请求，以生成预先签名的S3 URL
4. 收到URL后，将启动AJAX PUT请求，并将图像直接上载到S3。
5. 上传完成后，S3发送一条带有图像密钥的SQS队列消息
6. 其中一个工作人员接收到该消息并创建缩略图
7. 图像处理完成后，工作人员将缩略图上载到S3

现在，web层使用一个< code>db.json文件来保存所有现有缩略图的链接。使用该文件，客户端网页呈现网格中的所有缩略图。

问题是，网络层如何知道何时更新包含新缩略图链接的db.json？

理想情况下，web层将实现以下功能：

1. 仅在需要时刷新 json（如果 Web 层刷新了 json，则它必须已被修改）。
2. 更新后的 db.json 更新后提供更新的 db.json（如果在时间 x 上添加了缩略图，而另一个用户在时间 x 1 上请求了网页，则用户会知道新的缩略图）。

> < li>

对于每个< code>index.html请求，列出S3桶并提供最新的缩略图(违反上一节的第1项)。

按间隔列出 S3 存储桶（违反这两个项目）。

一旦请求了预先签名的URL，就设置定时器，并假设工作人员在定时器响铃时完成了对新图像的处理(这甚至不是解决方案，原因有两个:web层有多个实例，计时器可能会在处理完成前响起)。

使用 S3 事件并设置一个 lambda 表达式，该表达式将 HTTP GET 请求发送到我的 Web 层上的特殊终端节点（也不是解决方案，因为此请求将从负载均衡器定向到单个实例，那么其他实例呢？）。

我不知道如何解决这个问题。你建议我做什么？

由于这是一个教育练习，数据库服务超出了范围。

Answer 1

是数据库。json文件存储在一个web服务器上？如何协调数据库的更新。跨多个web服务器的json文件？如何防止多个工作服务器更新数据库。json文件，并同时相互踩在一起？

我建议将缩略图的存在存储在平面文件以外的其他位置。迪纳摩DB将是存储它的好地方。后格雷SQL或RDS上的一种MySQL风格也可以工作。

为了将JSON数据提供给包含缩略图列表的用户界面，我将创建一个查询数据库并呈现JSON数据的动态页面。这也将允许您实现数据分页之类的事情，一旦您的图像集变得非常大，这将是一个要求。

为了防止网络层因 JSON 数据请求而过载，我会在网络层前面放置一个 CDN（如云前瞻或云版）。为了防止数据库因缩略图列表的查询而过载，我会在 Web 层和数据库之间实现一个缓存层 （Redis）。

Answer 2

这个问题有点荒谬，因为将所有内容存储在一个JSON文件中的想法是不断更新的，但是解决方案似乎足够明显...另一个S3事件通知。

任何时候，如果你有一个系统给你提供了神奇的事件礼物，让你不必去调查任何事情，那么你就忽略了它所带来的价值。

如果每个web服务器都有自己的json文件副本，并且需要更新，这也很容易解决。

S3事件在创建缩略图时触发（S3通知可以匹配前缀，而不是整个bucket）

我有一个旧的遗留系统，其中网站模板更改（不是代码，只是模板）通过提交模板更改到subversion，然后在服务器上进行svn。由于此子版本存储库是为此目的而存在的，因此 Web 服务器直接从他的签出目录中读取模板。听起来很奇怪，但它已经服务了很多年。我最近通过设置一个让人想起上述内容的安排来增强它，但没有S3。当提交任何内容时，“提交后钩子”会在 subversion 服务器上触发一个 shell 脚本。反过来，这会将有关已更改文件的消息发布到 SNS 主题，该主题将扇出到多个 SQS 队列 - 每个 Web 服务器一个队列，并且每个服务器上的简单脚本侦听该服务器的 SQS 队列。每个服务器一个侦听器，一个线程，因此不存在并发问题。侦听器，它对新提交的文件运行“svn up”，删除队列消息，然后侦听下一个消息。实时事件扇出，为什么不呢？