这个问题可能太笼统了，但是这里...
我想接受用户上传的图像并将它们托管在 S3 上。这方面的最佳做法是什么？我在想以下几点:
Mysql - 创建一个包含所有图像元数据的表:
- 自增id
- 上传者的用户ID
- 指向其在 S3 中的位置的 slug 或路径
- 其他图像元数据？ (尺寸、宽度、高度等)
S3 - 创建一个新的存储桶来保存图像
网站后端 - 处理上传的逻辑:
- 接受用户上传、验证文件等
- 可选地处理图像(调整大小、转换等)
- 使用新的随机 slug 上传到适当的 S3 存储桶
- 如果成功，向mysql表中添加一条新记录
--
这是将 S3 用作带有我的 Web 服务的云提供商的标准做法吗？ 如何确保数据库和 S3 保持相互更新？例如，如果从数据库中手动删除一条记录会怎样？我应该如何处理孤立的 S3 对象？或者另一方面，如果图像从 S3 中删除但 mysql 表中没有对应的记录怎么办？ 是否只需要我编写一个脚本来验证两个系统之间的完整性？
最佳答案
查看 Get Bucket/List Objects 调用返回的信息。
http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html
特别是 Size、LastModified 和 ETag。
上传时将这些保存在您的表格中。
List objects 返回有关存储桶中对象的信息，对象按顺序列出，每个请求最多 1000 个对象，然后您可以从中断处继续下一个请求。
每 1,000 个请求 0.005 USD，您只需 0.04 USD，就可以在 8000 个请求中审计一个包含 800 万个对象(例如我拥有的对象)的存储桶。
ETag 特别重要，因为在 PUT 请求中，它会自动设置为对象主体的十六进制 md5 散列。 (在分段上传时，它是每个部分的串联二进制 md5 的十六进制 md5，后跟部分的数量)。有了这个容易获取的信息和大小，您就可以协调一些东西，并有理由保证桶中的对象正是您认为的那样。
然后编写一个获取对象列表的脚本，并定期与数据库进行比较。
想到的另一个重要的最佳实践是不要让分散的代码接触数据库和 S3。将涉及这两个方面的代码放在一起。
其他与一致性相关的想法...S3 中的 x-amz-meta-* 用户定义 header 非常有用；您可以在上传时设置它们，或者稍后通过 API 使用修改后的元数据“将对象复制到自身”来修改它们。您可以为每个对象存储约 8K 的元数据，例如将它与包含它的数据库行相关联的 id。此信息无法从“获取存储桶/列表对象”调用中获得，您必须针对特定对象发送 http HEAD 请求以获取元数据...但是如果您希望自己可以找出搁浅的桶对象来自何处，保存该信息会很好。 警告，任何有权下载该对象的人也会在响应 header 中获得元数据的副本(很容易看出他们是否正在查看)，因此您应该唯一存储在公共(public)或广泛可用的对象上的东西将是琐碎而不敏感的事情。 x-amz-meta-image-id: 1337 如果图像 id 的知识没有特别的后果，则可能是安全的。同样，如果它是一个调整大小的图像，存储原始源图像的 MD5 或 SHA 有助于以编程方式验证是的，“这个图像”是“那个图像”的一个调整大小的版本，即使有人得到了这个特定的元数据，它没有任何实际意义，因为我们拥有所有相关图像的权利。对于公共(public)内容，不应将任何敏感或个人数据存储在那里，但在非公共(public)对象上，元数据与对象本身一样安全。
关于mysql - 在 S3 上托管文件并使用 mysql，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26763053/