如果您使用S3来存储来自用户上传的数据,特别是在分布式环境中,一个重要的考虑因素是S3“最终是一致的”(尽管某些区域是写后读一致的).这样做的结果是您可以成功上传文件,但如果您之后立即检查其存在,可能会发现它不存在.对于诸如更新或删除之类的情况,此问题更为明显,即使是写后读写一致性也无济于事.

无论您采取何种方法,上述内容都适用于您上传到S3.实际上,对于人们可能期望的S3的大多数问题都是如此 – 用于存储数据的方法并非如此,因为S3的局限性可能是最成问题的.

S3fs使用S3 API – 就像PHP(或其他)SDK一样.此外,S3旨在处理相当高的并发性 – 因此(除了一致性问题)将它安装在多个实例上应该没有问题(请记住它不是传统的文件系统 – 锁定等问题,等等在S3方面处理).

也就是说,每种实现都有一些潜在的优点和缺点：

S3fs：

>不支持部分/分块下载(据我所知) – 所以你必须下载完整的文件来阅读它的任何部分 – 如果你只是用来存储(和提供)上传,可能不是问题.
>写在C可能的性能提升
>您的应用程序将受益于对s3fs的任何更新
>实现缓存(完整文件和文件信息) – 有可能提高速度,降低成本
>仅限于融合曝光的功能

SDK：

>公开S3提供的全套功能 – 根据您的使用情况,这可能足以值得使用SDK
>与您的应用程序可能更紧密地集成 – 返回的错误等可能允许您的应用程序做出更明智(因此更精确)的选择
>任何可能的优势都需要编码 – 您的应用程序必须利用它们并随时更新S3
>代码的复杂性和开销更大

就“安全”而言,您可能意味着“防止数据损坏”或“防止未经授权的访问”.关于前者,SDK可能有助于处理最终的一致性(以更详细的错误的形式),但底层存储是相同的,我希望差异很小.关于访问控制 – 您可以使用Iam创建受限帐户,但该帐户仍需要对S3文件进行读/写访问.两者都应该足够安全,在任何一种情况下,您的系统都需要被破坏才能访问您的S3存储桶 – 我建议使用S3fs(因为凭据通常存储在webroot之外,并且根本无法访问PHP)有更好的安全性.

个人意见：我赞成s3fs用于存在单个上传目录的情况(例如,一个站点使用它),并且访问将非常简单(只需要上传文件并偶尔更新/删除).如果您需要更复杂的访问(例如部分下载,多个存储桶等)或者将S3 SDK用于其他目的,那么我也会坚持使用SDK进行上传.