我的要求类似于任何社交网络平台。确切的细节是:
我看过this。摘要如下:
上传时比较棘手......
这方面的下载方面很好,但我对上传不太确定。 在创建联合用户之后,如果用户将文件上载到s3,然后告诉我的服务器路径名,则可以手动更改恶意意图的路径名。
如何执行以下操作:
我也欢迎有关存储桶结构命名的建议。 我想到了:
CONTENT(水桶名称) - > - > uuid命名文件
这意味着,如果有一百万个组,则会有一百万个组文件夹,后面跟一些表示文件本身的uuid。
我的服务器将记录uuids,并使用组ID计算绝对路径,组ID也将保存在我自己的服务器中。
答案 0 :(得分:2)
如果您的网站/应用程序永远不会那么繁忙,那么几乎所有命名约定都会起作用 - 所以您提到的结构会起作用,但通常出于性能原因,您最好没有大量的对象都是从相同的前缀 - 你想随机化对象名称的开头部分,而不是文件夹名称的结尾部分,所以如果你希望增长并且有一个非常繁忙的网站,你可能想要现在计划:< / p>
http://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html
Amazon S3维护每个AWS区域中的对象键名称索引。 对象键以多个UTF-8二进制顺序存储 索引中的分区。密钥名称决定了密钥的分区 存储在。使用顺序前缀,例如时间戳或 按字母顺序排列,增加了Amazon S3的可能性 针对大量密钥定位特定分区, 压倒了分区的I / O容量。 如果你介绍一些 密钥名称前缀中的随机性,密钥名称,以及密钥名称 I / O负载将分布在多个分区上。
<强>然而强>
本主题中的Amazon S3最佳做法指南仅适用于您 每秒定期处理100个或更多请求。如果你的 典型工作负载仅涉及偶尔突发100个请求 第二个,每秒少于800个请求,您不需要关注 这些准则。
答案 1 :(得分:2)
创建一个临时用户似乎有点矫枉过正,特别是当有更直接的方法可用时:
http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authentication-HTTPPOST.html
使用表单发布上传文件可以创建和签署无法篡改的策略文档,此策略文档不仅可以限制上传的密钥(路径) ,但也可以选择限制上传文件的大小 - S3将拒绝一个太大的文件。 (或小)。
还有一点可能澄清:
Amazon S3 API允许您为存储在S3中的任何私有对象生成临时URL。
这取决于“API”的含义。生成这些的不是S3 - 完全在本地代码中完成,而不与S3联系。 SDK具有为您执行此操作的代码,或者您可以使用已发布的规范编写自己的代码。我甚至编写了一个MySQL存储函数,它可以在查询中直接从数据库生成这些函数,并将URL作为参数。
根据您的应用程序,您可能还有兴趣了解CloudFront如何支持存储桶内容的预签名URL(CloudFront位于存储桶前面) - CloudFront预签名URL,使用“自定义策略”可以执行S3预先签名的URL无法做到的一些事情 - 限制按IP地址使用URL,并允许访问与特定路径模式匹配的所有对象 - 如{{1} }。
您可以使用匹配零个或多个字符(*)的通配符或字符串中任何位置恰好匹配一个字符(?)的通配符。
通过对此应用程序服务器进行一次签名,然后使用基本签名URL对每个可见对象的路径进行字符串替换,可以节省一些处理时间。这仅在CloudFront处理身份验证时有效 - 用于下载的S3签名URL不支持通配符。
签名URL非常快,但它确实涉及到幕后一些相当沉重的比特,所以如果从同一个html页面可以看到很多图像,那些毫秒就可以开始累加,这可能是一个有用的优化...更不用说您通常应该看到使用CloudFront更快下载,因为经常访问的对象被缓存到更靠近下载它们的用户。