OSS-对象存储介绍

目录

• 1 基本概念介绍
  • 1.1 存储空间（Bucket）
  • 1.2 对象/文件（Object）
  • 1.3 Region（区域）
  • 1.4 Endpoint（访问域名）
  • 1.5 AccessKey（访问密钥）
  • 1.6 强一致性
  • 1.7 OSS与文件系统的对比
  • 1.8 OSS 术语表
  • 1.9 OSS 使用场景：
• OSS与普通图床有什么区别？

1 基本概念介绍

1.1 存储空间（Bucket）

存储空间是您用于存储对象（Object）的容器，所有的对象都必须隶属于某个存储空间。您可以设置和修改存储空间属性用来控制地域、访问权限、生命周期等，这些属性设置直接作用于该存储空间内所有对象，因此您可以通过灵活创建不同的存储空间来完成不同的管理功能。

• 同一个存储空间的内部是扁平的，没有文件系统的目录等概念，所有的对象都直接隶属于其对应的存储空间。
• 每个用户可以拥有多个存储空间。
• 存储空间的名称在 OSS 范围内必须是全局唯一的，一旦创建之后无法修改名称。
• 存储空间内部的对象数目没有限制。

存储空间的命名规范如下：

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

1.2 对象/文件（Object）

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

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

对象的生命周期是从上传成功到被删除为止。在整个生命周期内，对象信息不可变更。重复上传同名的对象会覆盖之前的对象，因此，OSS 不支持修改文件的部分内容等操作。

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

对象的命名规范如下：

• 使用UTF-8编码。
• 长度必须在1-1023字节之间。
• 不能以“/”或者“\”字符开头。
• 对象名称需要区分大小写。如无特殊说明，本文档中的对象、文件称谓等同于 Object。

1.3 Region（区域）

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

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

1.4 Endpoint（访问域名）

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

1.5 AccessKey（访问密钥）

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

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

更多 AccessKey 介绍请参见 访问控制。

1.6 强一致性

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

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

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

1.7 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 应该充分发挥其优点，即海量数据处理能力，优先用来存储海量的非结构化数据，比如图片、视频、文档等。

1.8 OSS 术语表

英文	中文
Bucket	存储空间
Object	对象或者文件
Endpoint	OSS 访问域名
Region	区域或者数据中心
AccessKey	AccessKeyId 和 AccessKeySecret 的统称，访问密钥
Put Object	简单上传
Post Object	表单上传
Multipart Upload	分片上传
Append Object	追加上传
Get Object	简单下载
Callback	回调
Object Meta	文件元信息。用来描述文件信息，例如长度，类型等
Data	文件数据
Key	文件名
ACL (Access Control List)	存储空间或者文件的权限

1.9 OSS 使用场景：

• 图片分享
• 热点视频

OSS与普通图床有什么区别？

首先OSS是Object Storage Service 的简写，解决了服务器储存Blob(Binary Large Object)的需求。

Linuxext3文件系统，默认一个文件夹内最多只能当32000个文件

文件直接储存在服务器上还有安全性问题，如果黑客上传了二进制可执行文件并且通过漏洞运行了该文件，会导致无法预计的后果。

大型Web服务倾向于把业务逻辑，数据库，其他用户数据分开，而不是挤在同一个服务器里，好处很多，比如业务程序，数据库程序都有独立的cpu，稳定性更好，安全性高等。

文件分发又是一个问题，你可测试过跨与不夸运营商网络或地区的情况下，文件传输速度和延迟的差距？

其实oss没有目录的概念，我记得文件的key(可以理解为文件名)，是可以带有斜杠的，你自己按照目录的方式储存就行了，其实它只是一个key value pair而已

OSS并不是图床，而是可以储存任何文件的，并提供多节点数据分发的服务