Amazon云计算AWS之[3]简单存储对象S3

S3的基本概念和操作

• 简单存储服务（Simple Storage Services，S3）构架在Dynamo之上，用于提供任意类型文件的临时或永久性存储。S3的总体设计目标是可靠、易用及低成本。
• S3存储系统的基本结构，涉及两个基本概念：桶（Bucket）和对象（Object）
  

桶

• 桶是用于存储对象的容器，其作用类似于文件夹，但桶不可以被嵌套，即在桶中不能创建桶。
• Amazon限制每个用户创建桶的数量，但没有限制每个桶中对象的数量。
• 桶的名称要求在整个Amazon S3的服务器中是全局唯一的，避免在S3中数据共享时出现相互冲突的情况。
• 对桶命名，建议采用符合DNS要求的命名规则，以便与CloudFront等其他AWS服务配合使用。

---

通俗理解

• 想一想真实世界中的水桶。每个水桶可以用来装水，你可以有很多水桶，每个水桶可以放在不同的地方，可以贴上不同的标签（例如“花园用水”、“厨房用水”等），并且每个水桶都有自己的容量限制。不过，在S3服务中，桶里装的不是水，而是数据。

• 在Amazon S3这个“云存储服务”里，桶（Bucket）是用来装你所有文件（在这里称为对象或Object）的地方。你可以想象它们就像是电脑上的文件夹，不过这些“文件夹”可以无限大，可以存储任何量的数据。

• 每个桶都有一个独一无二的名字，全球范围内都不能重复，这就像是你给你的桶贴上了一个全世界唯一的标签，确保你发给朋友的地址只指向你的桶，而不是别人的。此外，桶可以设置权限，决定谁可以看到桶里的内容，谁可以向桶里添加内容等。这就像给你的桶上了一把锁，你可以决定谁有钥匙。

对象

• 对象是S3的基本存储单元，主要由数据和元数据组成。
• 数据可以是任意类型，但大小受到对象最大容量的限制。
• 元数据是数据内容的附加描述信息，通过名称-值（name-value）集合的形式来定义，可以是系统默认的元数据（System Metadata）或用户指定的自定义元数据（User Metadata）。

• 每个对象在所在的桶中有唯一的键（key）。通过将桶名和键相结合的方式，可以标识每个对象。
• 键在对象创建后无法被更改，即重命名对于S3中的对象是无效的。
• S3中对象的存储在默认情况下是不进行版本控制的。但S3中提供了版本控制的功能，用于存档早期版本的对象或者防止对象被误删。版本控制只能对于桶内所有的对象启用，而无法具体对某个对象启用版本控制。当对某个桶启用版本控制后，桶内会出现键相同但版本号不同的对象，此时对象需要通过“桶名+键+版本号”的形式来唯一标识。

基本操作

• S3中支持对桶和对象的操作，主要包括：Get、Put、List、Delete和Head。

S3的数据一致性模型

基知：CAP理论

CAP定理，又称布鲁尔定理（Brewer’s theorem），指出分布式系统不可能同时满足以下三个基本保证中的超过两个：

1. 一致性（Consistency）：所有节点在同一时间具有相同的数据。
2. 可用性（Availability）：保证每个请求不管成功或者失败都有响应。
3. 分区容忍性（Partition tolerance）：系统在网络分区发生时，仍能继续运行。

对于Amazon S3这样的分布式系统，它设计上主要满足以下两个要素：

• 可用性（Availability）：S3确保在网络分区或其他故障时，用户的请求仍然可以被响应，尽管响应中的数据可能不是最新的。

• 分区容忍性（Partition tolerance）：S3能够处理网络分区，即使一部分节点无法通信，系统也能继续运作。数据会在内部进行复制，以确保当网络分区恢复后系统可以同步数据，达到最终一致性状态。

S3的最终一致性

• S3中采用最终一致性模型。

• 在分布式系统中，一致性模型定义了系统中数据副本更新后可见性的规则和时限。

• 一致性在S3中是最终一致性，而非强一致性。这意味着系统可能会在一段时间内出现数据不一致的情况，但最终会达到一致的状态。因此，S3的设计是为了在保证可用性和分区容忍性的前提下，通过最终一致性模型来尽可能提供一致性保证。

• 在最终一致性模型下，如果没有新的更新操作，那么经过一段时间，所有的数据副本最终将会是一致的。换句话说，一个成功执行的写操作（如上传文件、修改文件）会在一段时间后对所有读操作（如获取文件）可见。

• 在S3中上传或修改一个文件后，这些更改可能不会立即对所有用户可见。例如，一个用户可能会在上传文件几秒钟到几分钟后才能看到最新的文件版本。因为亚马逊的数据中心可能需要时间来传播和同步这些更改。

• 在数据被充分传播到所有的存放节点之前，服务器返回给用户的仍是原数据，此时用户操作可能会出现如下情况。（了解）

S3的安全措施

• 对于用户来说，系统的易用性是其考虑的一方面，但最终决定其是否使用S3服务的通常是S3的安全程度。
• S3向用户提供包括身份认证（Authentication）和访问控制列表（ACL）的双重安全机制

身份认证（Authentication）

• S3中使用基于HMAC-SHA1的数字签名方式来确定用户身份。HMAC-SHA1是一种安全的基于加密Hash函数和共享密钥的消息认证协议，它可以有效地防止数据在传输过程中被截获和篡改，维护数据的完整性、可靠性和安全性。

• HMAC-SHA1消息认证机制的成功在于一个加密的Hash函数、一个加密的随机密钥和一个安全的密钥交换机制。

• 在新用户注册时，Amazon给每个用户分配一个Access Key ID和一个Secret Access Key。

  • Access Key ID是一个20位的由字母和数字组成的串，用来确定服务请求的发送者
  • Secret Access Key是一个40位的字符串，参与数字签名过程，用来证明用户是发送服务请求的账户的合法拥有者。

---

• S3数字签名具体实现过程
  

1. S3用户首先发出服务请求，系统会自动生成一个服务请求字符串。
2. HMAC函数负责计算用户的服务请求字符串和Secret Access Key生成的数字签名，并将这个签名和服务请求字符串一起传给S3服务器。
3. 服务器接收到信息后会从中分离出用户的AccessKey ID，通过查询S3数据库得到用户的Secret Access Key。
4. 利用和上面相同的过程生成一个数字签名，然后和用户发送的数字签名做比对，相同则通过验证，反之拒绝。

访问控制列表（ACL）

• 访问控制列表（Access Control Policy）是S3提供的可供用户自行定义的访问控制策略列表。

访问控制策略(ACP)

• S3的访问控制策略（Access Control Policy，ACP）提供如下五种访问权限。
  
• 注意：WRITE_ACP具有覆写对象和桶的ACP权限，所以可以通过覆写简介获得read、write、read_acp等权限。
• 注意：S3的ACL不具有继承性:$桶和对象的ACL各自独立$，对桶有某种访问权限不代表对桶中的对象也具有相同的权限

授权用户类型

• S3中有三大类型的授权用户，分别是所有者（Owner）、个人授权用户（User）和组授权用户（Group）

• 所有者（Owner）：桶或对象的创建者，$默认具是WRITE\_ACP权限$。所有者本身也要服从ACL，如果该所有者没有$READ\_ACP$，则无法读取ACL。但是所有者可以通过覆写相应桶或对象的ACP获取想要的权限，从这个意义上来说，所有者默认就是最高权限拥有者

• 个人授权用户（User）：两种授权方式，一种是通过电子邮件地址授权的用户，另一种是通过用户ID进行授权。后
  一种方式比较麻烦，因为ID是一个不规则的字符串，用户在授权的过程中容易出错。电子邮件地址方式授权的方法最终还是在S3服务器内部转换成相应的用户ID进行授权。

• 组授权用户（Group）：一种是AWS用户组，它将授权分发给所有AWS账户拥有者；另一种是所有用户组(允许匿名访问，有潜在危险，不建议使用)