Amazon S3 架构 [关闭]答案

【问题标题】：Amazon S3 architecture [closed]Amazon S3 架构 [关闭]
【发布时间】：2009-02-19 06:57:08
【问题描述】：

虽然@http://highscalability.com/amazon-architecture 的帖子对 Amazon 的架构进行了概括说明，但我有兴趣了解 Amazon S3 是如何实现的。

我的一些猜测是

类似 HDFS 的分布式文件系统 http://hadoop.apache.org/core/docs/current/hdfs_design.html
像 CouchDB 这样的非关系持久数据库 http://couchdb.apache.org/

是否可以使用 Python 或 PHP 等脚本语言在更小范围内实现类似的功能？

【问题讨论】：

至少有one S3 等效解决方案可用于测试客户端。通过研究源代码，您可能会发现一些信息，也许您可以在自己的项目中使用它。
看看 MogileFS。它的 API 与 S3 不兼容，并且功能比 S3 少很多，但它完成了在一组低成本存储服务器上分发静态文件的基本过程。

标签： amazon-web-services hadoop amazon-s3 couchdb distributed-system

【解决方案1】：

Amazon S3 是使用 Dynamo 论文中描述的架构实现的：

http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html

该论文解释了一致性哈希，以及保证“最终一致性”的方式和原因。

他们为 Dynamo 讨论的冲突解决方案并未向 S3 用户公开。它在 Amazon 的应用程序内部使用，但对于 S3，唯一的冲突解决方案是最后写入获胜。

编辑：Werner Vogels 曾说过“Dynamo 并未作为 Web 服务直接暴露在外部；但是，Dynamo 和类似的 Amazon 技术用于为我们的 Amazon Web Services 的某些部分提供动力，例如 S3。” http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html

我要强调的是，他并不是说 S3 和 Dynamo 共享组件，他明确表示 Dynamo 本身就是支持 S3 的技术之一。我从 S3 中看到的所有内容（包括警告）都是通过假设 S3 是一个围绕 Dynamo 的精美 Web 服务包装器，具有身份验证、记帐和用户不可见的最后写入胜出冲突解决方案。

最初的问题是关于 S3 的底层存储机制。它显然不是像 HDFS 这样的分布式文件系统，也不是像 CouchDB 这样的非关系数据库。 Dynamo 填补了这个角色。

【讨论】：

我不认为这是完全正确的。 Dynamo 的目标与 S3（Dynamo 用于购物车和类似用例、大量写入、应用程序提供的冲突解决、短值）与 S3（简单的键/值存储，具有大值，没有基于内容的冲突）有很大不同解决或合并。因此，内部实现和设计完全不同（AFAIK）。在架构上，它们共享许多东西，以及一些内部组件。
Dynamo 和 S3 是完全不同的架构
Dynamo 可能用于 S3 的某些部分（例如元数据存储），但主存储结构完全不相关

【解决方案2】：

无论是 Amazon S3 的架构还是它的执行情况尚未公布。像这样，它不可用于扩展以开发创建任何规模的私有云的能力。

有几篇关于云存储架构主题的论文。您可能会发现它们很有用。这是一个：CACSS: Towards a Generic Cloud Storage Service

不同的方法技术可以结合起来提供单一的卓越性能、高度可扩展和可靠的云存储系统也很详细。这项研究可作为经验不足的云的知识来源供应商，使他们能够快速建立自己的云存储服务

【讨论】：

【解决方案3】：

它更接近于 2，尽管内容存储为“BLOB”，系统不关心内容，而 CouchDB 可以。后端存储对用于存储多个副本的集群节点使用本地数据库（BDB？）。读取可以转到任何具有副本的节点，写入也可以，但是需要解决写入以消除冲突。正如 Kevin 所提到的，这保证了“最终一致性”，但没有严格保证何时或哪个写入获胜（来自外部 POV；内部已定义）。

阅读 Dynamo 文档有助于理解许多概念，但 AFAIK 的实现有所不同。 Dynamo 被亚马逊内部用于其他用途。两者都有开源实现；一个有趣的是Project Voldemort。 CouchDB 显然也很有趣。

【讨论】：