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並不是圖床，而是可以儲存任何文件的，並提供多節點數據分發的服務