在S3上托管文件并使用mysql

Jef*_*eff 5 mysql database amazon-s3 amazon-web-services

这个问题可能过于笼统,但这里......

我想接受用户上传的图片并在S3上托管它们.这是最好的做法是什么?我在考虑以下几点:

Mysql - 创建一个包含所有图像元数据的表:

  • 自动递增ID
  • 上传者的用户ID
  • 指向其在S3中的位置的slu or或路径
  • 其他图像元数据?(尺寸,宽度,高度等)

S3 - 创建一个新桶以保存图像

站点后端 - 处理上传的逻辑:

  1. 接受用户上传,验证文件等
  2. 可选择处理图像(调整大小,转换等)
  3. 使用新的随机slug上传到相应的S3存储桶
  4. 如果成功,请将新记录添加到mysql表中

-

这是使用S3作为我的Web服务的云提供商的标准做法吗?如何确保数据库和S3保持彼此更新?例如,如果从数据库中手动删除记录会发生什么?我该如何处理孤立的S3对象?或者另一方面,如果从S3删除图像而不是mysql表中的相应记录呢?是否由我来编写一个验证两个系统之间完整性的脚本?

Mic*_*bot 6

查看Get Bucket/List Objects调用返回的信息.

http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html

特别是Size,LastModified和ETag.

上传时将这些保存在表格中.

列表对象返回有关桶中对象的信息,对象按顺序列出,每个请求最多1000个对象,然后您可以使用下一个请求继续上次停止的位置.

以每1,000个请求0.005美元的价格,您可以在8000个请求中审核一个包含800万个对象(例如我拥有的对象)的存储桶,价格为0.04美元.

ETag特别重要,因为在PUT请求时,它会自动设置为对象正文的hex md5哈希值.(在分段上传中,它是每个部分的级联二进制md5的十六进制md5,后跟部分的数量).通过这些易于获取的信息和大小,您可以协调并合理地确保存储桶中的对象正是您认为的那样.

然后编写一个获取对象列表的脚本,并定期与数据库进行比较.

想到的另一个重要的最佳实践是不要让分散的代码触及数据库和S3.保持将两者结合在一起的代码.


其他与一致性相关的思想...... x-amz-meta-*S3中用户定义的标题非常有用; 你可以在上传时设置它们,或者稍后通过带有修改后的元数据的API"将对象复制到自身"来修改它们.您可以为每个对象存储~8K的元数据,例如将其与包含它的数据库行相关联的ID.此信息不能从"获取存储桶/列表对象"调用中获得,您必须HEAD针对特定对象发送http 请求以获取元数据...但是如果您希望您能够找出搁浅的存储桶对象的位置来自,保存这些信息会很好. 警告,任何有权下载对象的人也会在响应头中获取元数据的副本(很容易看出他们是否正在查看),因此您应该在公共或广泛可用的对象上存储的唯一内容将是微不足道的事情.不敏感. x-amz-meta-image-id: 1337如果图像id的知识没有特别的后果,那么可能是安全的.同样,如果它是一个已调整大小的图像,存储原始源图像的MD5或SHA有助于编程验证,是的,"此图像"是"该图像"的调整大小版本,即使有人掌握了这个特定的元数据,它没有任何实际意义,因为我们拥有所有相关图像的权利.不应将任何敏感或个人数据存储在那里用于公共内容,但在非公共对象上,元数据与对象本身一样安全.