OSS基本概念介绍

Bucket（存储空间）

Bucket是一个用户用来管理所存储Object的存储空间。 每个用户可以拥有多个Bucket。Bucket的名称在OSS的范围内必须是全局唯一的，一旦创建之后无法修改名称。Bucket内部的Object数目是没有限制的。

Bucket对于用户来说是一个管理Object的单元，所有的Object都必须隶属于某个Bucket。Bucket有一些属性用来控制Region、Object的访问控制、Object的生命周期等，这些属性是作用在该Bucket下所有的Object上的，因此用户可以灵活创建不同的Bucket来完成不同的管理功能。

同一个Bucket内部的空间是扁平的，即没有文件系统的目录等概念，所有的Object都是直接隶属于其对应的Bucket。

• Bucket命名规范
  • 只能包括小写字母，数字和短横线（-）
  • 必须以小写字母或者数字开头
  • 长度必须在3-63字节之间

Object（对象，文件）

Object是OSS存储数据的基本单元，称为OSS的对象，也被称为OSS的文件。在本文中，Object，对象，文件指的都是同一个意思。 Object由元信息（Object Meta），用户数据（Data）和文件名（Key）组成。 Object由一个在Bucket内部唯一的Key来标示。Object Meta信息是一个键值对，表示了Object的一些属性，比如最后修改时间、大小等信息，同时用户也可以存储一些自定义的信息在Object Meta信息中。

根据不同的上传方式，Object的大小限制是不一样的。分片上传最大支持48.8TB的Object大小，其他的上传方式最大支持5GB。

Object在整个存储的生命周期内都是不可变的。一个Object的生命周期是从上传成功到被删除为止。重复上传同名的Object会导致老的Object被删除然后新的Object取而代之。因此在OSS中，不支持类似文件系统的修改部分内容等操作。

OSS提供了追加上传功能，用户可以使用该功能不断地在Object尾部追加写入数据。

• Object命名规范 　使用UTF-8编码 　长度必须在1-1023字节之间 *　不能以“/”或者“\”字符开头

注意:Object的名字是大小写敏感的。如无特殊说明，本文档中的文件等同于Object。

Region（区域）

Region表示OSS的数据中心所在的区域，物理位置。 用户可以根据费用、请求来源等综合选择数据存储的Region。一般来说，距离用户更近的Region访问速度更快。详细请查看OSS已经开通的Region。

Region是在创建Bucket的时候指定的，一旦指定之后就不允许更改，该Bucket下所有的Object都存储在对应的数据中心，目前不支持Object级别的Region设置。

Endpoint（访问域名）

Endpoint表示OSS对外服务的访问域名。 OSS以HTTP REST API的形式对外提供服务，当访问不同的Region的时候，需要不同的域名。通过内网和外网访问同一个Region所需要的Endpoint也是不同的。例如杭州Region的外网Endpoint就是oss-cn-hangzhou.aliyuncs.com，内网Endpoint是oss-cn-hangzhou-internal.aliyuncs.com。更具体的内容可以参考各个Region对应的Endpoint。

AccessKey（访问密钥）

AccessKey，简称AK，指的是访问身份验证中用到的AccessKeyId和AccessKeySecret。 OSS通过使用AccessKeyId和AccessKeySecret对称加密的方法来验证某个请求的发送者身份。AccessKeyId用于标示用户，AccessKeySecret是用户用于加密签名字符串和OSS用来验证签名字符串的密钥，其中AccessKeySecret必须保密。对于OSS来说，AccessKey的来源有：

• Bucket的拥有者申请的AccessKey。
• 被Bucket的拥有者通过RAM授权第三方请求者的AccessKey。
• 被Bucket的拥有者通过STS授权第三方请求者的AccessKey。

更多AccessKey介绍见访问控制。

强一致性

Object操作在OSS上具有原子性，操作要么成功要么失败，不会存在有中间状态的Object。OSS保证用户一旦上传完成之后读到的Object是完整的，OSS不会返回给用户一个只上传成功了部分的Object。

Object操作在OSS上同样具有强一致性，用户一旦收到了一个上传（PUT）成功的响应，该上传的Object就已经立即可读，并且数据的三份副本已经写成功。不存在一种上传的中间状态，即read-after-write却无法读取到数据。对于删除操作也是一样的，用户删除指定的Object成功之后，该Object立即变为不存在。

强一致性方便了用户架构设计，可以像使用传统存储设备一样的逻辑使用OSS，修改立即可见，无需考虑最终一致性带来的各种问题。

OSS与文件系统的对比

OSS是一个分布式的对象存储服务，提供的是一个Key-Value对形式的对象存储服务。用户可以根据Object的名称（Key）唯一的获取该Object的内容。虽然用户可以使用类似test1/test.jpg的名字，但是这并不表示用户的Object是保存在test1目录下面的。对于OSS来说，test1/test.jpg仅仅只是一个字符串，和a.jpg这种并没有本质的区别。因此不同名称的Object之间的访问消耗的资源是类似的。

文件系统是一种典型的树状的索引结构，一个名为test1/test.jpg的文件，访问过程需要先访问到test1这个目录，然后再在该目录下查找名为test.jpg的文件。因此文件系统可以很轻易的支持文件夹的操作，比如重命名目录、删除目录、移动目录等，因为这些操作仅仅只是对了目录节点的操作。这种组织结构也决定了文件系统访问越深的目录消耗的资源也越大，操作拥有很多文件的目录也会非常慢。

对于OSS来说，可以通过一些操作来模拟类似的功能，但是代价非常昂贵。比如重命名目录，希望将test1目录重命名成test2，那么OSS的实际操作是将所有以test1/开头的Object都重新复制成以test2/开头的Object，这是一个非常消耗资源的操作。因此在使用OSS的时候要尽量避免类似的操作。

OSS保存的Object是不支持修改的（追加写Object需要调用特定的接口，生成的Object也和正常上传的Object类型上有差别）。用户哪怕是仅仅需要修改一个字节也需要重新上传整个Object。而文件系统的文件是支持修改，比如修改指定偏移位置的内容、截断文件尾部等，这些特点也使得文件系统拥有广泛的适用性。但另外一方面，OSS能支持海量的用户并发访问，而文件系统会受限于单个设备的性能。

因此，将OSS映射为文件系统是非常低效的，也是不建议的做法。如果一定要挂载成文件系统的话，也尽量只做写新文件、删除文件、读取文件这几种操作。使用OSS应该充分发挥其优点，即海量数据处理能力，优先用来存储海量的非结构化数据，比如图片、视频、文档等。

以下是OSS与文件系统的概念对比：

OSS术语表

注意:在这篇文章中，如果没有特殊说明，出现和术语表中相同的英文和中文，表达的是相同的意思。有时候为了表述方便会混合使用。