對象存儲是一個相對較新并且在持續(xù)穩(wěn)步增長的市場部分。對于新手而言，對象存儲用于保存大量非結(jié)構(gòu)化數(shù)據(jù)，其中每個“對象”實(shí)際上是一個沒有特定格式的文件(也稱二進(jìn)制文件)。實(shí)際上，從小的對象(人類可讀取文件)到媒體(音頻和視頻)或其它行業(yè)特定格式(石油&天然氣，醫(yī)學(xué)成像等)，對象存儲可以保存任何類型的數(shù)據(jù)。

與傳統(tǒng)存儲相比，采用對象存儲的好處良多?；趬K的系統(tǒng)(例如光纖通道和iSCSI)無法很好地向外擴(kuò)展，并且沒有真正的了解所存儲的數(shù)據(jù)。它們是以低延遲和高粒度提供內(nèi)容的“啞”塊設(shè)備。文件系統(tǒng)將一些結(jié)構(gòu)放在數(shù)據(jù)上，將文件對象放入層級結(jié)構(gòu)(文件夾/目錄)然后將元數(shù)據(jù)附加到這些對象上。然而，元數(shù)據(jù)通常只是基于存儲文件所需的信息(創(chuàng)建時間，時間更新，訪問規(guī)則)存儲文件。

對象存儲更進(jìn)一步消除了文件夾層次結(jié)構(gòu),具有高度可搜索的可擴(kuò)展元數(shù)據(jù)。在規(guī)模方面，對象存儲可以增加到多(即便不是上百)PB容量，通常對數(shù)據(jù)沒有地域限制。因?yàn)閷ο蟠鎯ζ脚_提供了優(yōu)于傳統(tǒng)存儲的形式，越來越多的企業(yè)開始采用它。基于塊的存儲陣列無法很好地擴(kuò)展，且?guī)в写罅縃DD和SSD的數(shù)據(jù)保護(hù)(例如RAID)的問題?；谖募南到y(tǒng)受到系統(tǒng)自身的可擴(kuò)展性限制，無論是在對象計數(shù)、并發(fā)、并行訪問或恢復(fù)時間方面，都能檢驗(yàn)出文件系統(tǒng)結(jié)構(gòu)的一致性。對象存儲代表一種更簡單、更可擴(kuò)展的解決方案，通過標(biāo)準(zhǔn)的基于網(wǎng)絡(luò)的協(xié)議可輕松訪問。

我們都知道，保存像圖片、音視頻這類大文件，最佳的選擇就是 對象存儲。對象存儲不僅有很好的 大文件讀寫性能，還可以 通過水平擴(kuò)展實(shí)現(xiàn)近乎無限的容量，并且可以 兼顧服務(wù)高可用、數(shù)據(jù)高可靠 這些特性。

對象存儲之所以能做到這么「全能」，最主要的原因是，對象存儲是原生的分布式存儲系統(tǒng)。這里我們講的「原生分布式存儲系統(tǒng)」，是相對于 MySQL、Redis 這類單機(jī)存儲系統(tǒng)來說的。雖然這些非原生的存儲系統(tǒng)，也具備一定的集群能力，但你也能感受到，用它們構(gòu)建大規(guī)模分布式集群的時候，其實(shí)是非常不容易的。

隨著云計算的普及，很多新生代的存儲系統(tǒng)，都是原生的分布式系統(tǒng)，它們一開始設(shè)計的目標(biāo)之一就是分布式存儲集群，比如說 Elasticsearch、Ceph 和國內(nèi)很多大廠推出的新一代數(shù)據(jù)庫，大多都可以做到：

• 近乎無限的存儲容量；
• 超高的讀寫性能；
• 數(shù)據(jù)高可靠：節(jié)點(diǎn)磁盤損毀不會丟數(shù)據(jù)；
• 實(shí)現(xiàn)服務(wù)高可用：節(jié)點(diǎn)宕機(jī)不會影響集群對外提供服務(wù)。

那這些原生分布式存儲是如何實(shí)現(xiàn)這些特性的呢？這里面同樣存在嚴(yán)重的「互相抄作業(yè)」的情況。這個也可以理解，除了存儲的數(shù)據(jù)結(jié)構(gòu)不一樣，提供的查詢服務(wù)不一樣以外，這些分布式存儲系統(tǒng)，它們面臨的很多問題都是一樣的，那實(shí)現(xiàn)方法差不多也是可以理解。

對象存儲的查詢服務(wù)和數(shù)據(jù)結(jié)構(gòu)都非常簡單，是最簡單的原生分布式存儲系統(tǒng),對象存儲數(shù)據(jù)是如何保存大文件的？

對象存儲對外提供的服務(wù)，其實(shí)就是一個 近乎無限容量的大文件 KV 存儲，所以對象存儲和分布式文件系統(tǒng)之間，沒有那么明確的界限。對象存儲的內(nèi)部，肯定有很多的存儲節(jié)點(diǎn)，用于保存這些大文件，這個就是數(shù)據(jù)節(jié)點(diǎn)的集群。

另外，我們?yōu)榱斯芾磉@些數(shù)據(jù)節(jié)點(diǎn)和節(jié)點(diǎn)中的文件，還需要一個存儲系統(tǒng)保存集群的節(jié)點(diǎn)信息、文件信息和它們的映射關(guān)系。這些為了管理集群而存儲的數(shù)據(jù)，叫做元數(shù)據(jù) (Metadata)。

元數(shù)據(jù)對于一個存儲集群來說是非常重要的，所以保存元數(shù)據(jù)的存儲系統(tǒng)必須也是一個集群。但是元數(shù)據(jù)集群存儲的數(shù)據(jù)量比較少，數(shù)據(jù)的變動不是很頻繁，加之客戶端或者網(wǎng)關(guān)都會緩存一部分元數(shù)據(jù)，所以元數(shù)據(jù)集群對并發(fā)要求也不高。一般使用類似 ZooKeeper 或者 etcd 這類分布式存儲就可以滿足要求。

另外，存儲集群為了對外提供訪問服務(wù)，還需要一個 網(wǎng)關(guān)集群，對外接收外部請求，對內(nèi)訪問元數(shù)據(jù)和數(shù)據(jù)節(jié)點(diǎn)。網(wǎng)關(guān)集群中的每個節(jié)點(diǎn)不需要保存任何數(shù)據(jù)，都是無狀態(tài)的節(jié)點(diǎn)。有些對象存儲沒有網(wǎng)關(guān)，取而代之的是客戶端，它們的功能和作用都是一樣的。

那么，對象存儲是如何來處理對象讀寫請求的呢？這里面處理讀和寫請求的流程是一樣的，我們一起來說。網(wǎng)關(guān)收到對象讀寫請求后，首先拿著請求中的 Key，去元數(shù)據(jù)集群查找這個 Key 在哪個數(shù)據(jù)節(jié)點(diǎn)上，然后再去訪問對應(yīng)的數(shù)據(jù)節(jié)點(diǎn)讀寫數(shù)據(jù)，最后把結(jié)果返回給客戶端。

以上是一個比較粗略的大致流程，實(shí)際上這里面包含很多的細(xì)節(jié)，我們暫時沒有展開講。目的是讓你在整體上對對象存儲，以至于分布式存儲系統(tǒng)，有一個清晰的認(rèn)知。

對象是如何拆分和保存的？

一般來說，對象存儲中保存的文件都是圖片、視頻這類大文件。在對象存儲中，每一個大文件都會被拆成多個大小相等的塊兒（Block），拆分的方法很簡單，就是把文件從頭到尾按照固定的塊兒大小，切成一塊兒一塊兒，最后一塊兒長度有可能不足一個塊兒的大小，也按一塊兒來處理。塊兒的大小一般配置為幾十 KB 到幾個 MB 左右。

把大對象文件拆分成塊兒的目的有兩個：

1. 第一是為了 提升讀寫性能，這些塊兒可以分散到不同的數(shù)據(jù)節(jié)點(diǎn)上，這樣就可以并行讀寫。
2. 第二是 把文件分成大小相等塊兒，便于維護(hù)管理。

對象被拆成塊兒之后，還是太過于碎片化了，如果直接管理這些塊兒，會導(dǎo)致元數(shù)據(jù)的數(shù)據(jù)量會非常大，也沒必要管理到這么細(xì)的粒度。所以一般都會再把塊兒聚合一下，放到塊兒的容器里面。

這里的「容器」就是存放一組塊兒的邏輯單元。容器這個名詞，沒有統(tǒng)一的叫法，比如在 ceph 中稱為 Data Placement。容器內(nèi)的塊兒數(shù)大多是固定的，所以容器的大小也是固定的。

到這里，這個 容器的概念，就比較 類似 于我們之前講 MySQL 和 Redis 時提到的**「分片」的概念** 了，都是復(fù)制、遷移數(shù)據(jù)的基本單位。每個容器都會有 N 個副本，這些副本的數(shù)據(jù)都是一樣的。其中有一個主副本，其他是從副本，主副本負(fù)責(zé)數(shù)據(jù)讀寫，從副本去到主副本上去復(fù)制數(shù)據(jù)，保證主從數(shù)據(jù)一致。

對象存儲一般都不記錄類似 MySQL 的 Binlog 這樣的日志。主從復(fù)制的時候，復(fù)制的不是日志，而是整塊兒的數(shù)據(jù)。這么做有兩個原因：

1. 第一個原因是基于性能的考慮。
   我們知道操作日志里面，實(shí)際上就包含著數(shù)據(jù)。在更新數(shù)據(jù)的時候，先記錄操作日志，再更新存儲引擎中的數(shù)據(jù)，相當(dāng)于在磁盤上串行寫了 2 次數(shù)據(jù)。對于像數(shù)據(jù)庫這種，每次更新的數(shù)據(jù)都很少的存儲系統(tǒng)，這個開銷是可以接受的。但是對于對象存儲來說，它每次寫入的塊兒很大，兩次磁盤 IO 的開銷就有些不太值得了。
2. 第二個原因是它的存儲結(jié)構(gòu)簡單，即使沒有日志，只要按照順序，整塊兒的復(fù)制數(shù)據(jù)，仍然可以保證主從副本的數(shù)據(jù)一致性。

以上我們說的 對象（也就是文件）、塊兒和容器，都是 邏輯層面的概念，數(shù)據(jù)落實(shí)到副本上，這些副本就是真正物理存在了。這些副本再被分配到 數(shù)據(jù)節(jié)點(diǎn) 上保存起來。這里的數(shù)據(jù)節(jié)點(diǎn)就是運(yùn)行在服務(wù)器上的服務(wù)進(jìn)程，負(fù)責(zé)在本地磁盤上保存副本的數(shù)據(jù)。

了解了對象是如何被拆分并存儲在數(shù)據(jù)節(jié)點(diǎn)上之后，我們再來回顧一下數(shù)據(jù)訪問的流程。當(dāng)我們請求一個 Key 的時候，網(wǎng)關(guān)首先去元數(shù)據(jù)中查找這個 Key 的元數(shù)據(jù)。然后根據(jù)元數(shù)據(jù)中記錄的對象長度，計算出對象有多少塊兒。接下來的過程就可以分塊兒并行處理了。對于每個塊兒，還需要再去元數(shù)據(jù)中，找到它被放在哪個容器中。

我剛剛講過，容器就是分片，怎么把塊兒映射到容器中，這個方法就是我們在《MySQL 存儲海量數(shù)據(jù)的最后一招：分庫分表》 課中講到的幾種分片算法。不同的系統(tǒng)選擇實(shí)現(xiàn)的方式也不一樣，有用哈希分片的，也有用查表法把對應(yīng)關(guān)系保存在元數(shù)據(jù)中的。找到容器之后，再去元數(shù)據(jù)中查找容器的 N 個副本都分布在哪些數(shù)據(jù)節(jié)點(diǎn)上。然后，網(wǎng)關(guān)直接訪問對應(yīng)的數(shù)據(jù)節(jié)點(diǎn)讀寫數(shù)據(jù)就可以了。

對象存儲是最簡單的分布式存儲系統(tǒng)，主要由 數(shù)據(jù)節(jié)點(diǎn)集群、**元數(shù)據(jù)集群 **和 **網(wǎng)關(guān)集群（或者客戶端）**三部分構(gòu)成。

• 數(shù)據(jù)節(jié)點(diǎn)集群：負(fù)責(zé)保存對象數(shù)據(jù)，
• 元數(shù)據(jù)集群：負(fù)責(zé)保存集群的元數(shù)據(jù)，
• 網(wǎng)關(guān)集群和客戶端：對外提供簡單的訪問 API，對內(nèi)訪問元數(shù)據(jù)和數(shù)據(jù)節(jié)點(diǎn)讀寫數(shù)據(jù)。

為了便于維護(hù)和管理，大的對象被拆分為若干固定大小的塊兒，塊兒又被封裝到容器（也就分片）中，每個容器有一主 N 從多個副本，這些副本再被分散到集群的數(shù)據(jù)節(jié)點(diǎn)上保存。

對象存儲雖然簡單，但是它具備一個分布式存儲系統(tǒng)的全部特征。所有分布式存儲系統(tǒng)共通的一些特性，對象存儲也都具備，比如說數(shù)據(jù)如何分片，如何通過多副本保證數(shù)據(jù)可靠性，如何在多個副本間復(fù)制數(shù)據(jù)，確保數(shù)據(jù)一致性等等。

不僅是學(xué)會對象存儲，還要對比分析一下，對象存儲和其他分布式存儲系統(tǒng)，比如 MySQL 集群、HDFS、Elasticsearch 等等這些，它們之間有什么共同的地方，差異在哪兒。想通了這些問題，你對分布式存儲系統(tǒng)的認(rèn)知，絕對會上升到一個全新的高度。然后你再去看一些之前不了解的存儲系統(tǒng)，就非常簡單了。

對象存儲并不是基于日志來進(jìn)行主從復(fù)制的。假設(shè)我們的對象存儲是一主二從三個副本，采用半同步方式復(fù)制數(shù)據(jù)，也就是主副本和任意一個從副本更新成功后，就給客戶端返回成功響應(yīng)。主副本所在節(jié)點(diǎn)宕機(jī)之后，這兩個從副本中，至少有一個副本上的數(shù)據(jù)是和宕機(jī)的主副本上一樣的，我們需要找到這個副本作為新的主副本，才能保證宕機(jī)不丟數(shù)據(jù)。

但是沒有了日志，如果這兩個從副本上的數(shù)據(jù)不一樣，我們?nèi)绾未_定哪個上面的數(shù)據(jù)是和主副本一樣新呢？一般都是基于版本號來解決，在 Leader上，KEY 每更新一次，KEY 的版本號就加 1，版本號作為 KV 的一個屬性，一并復(fù)制到從節(jié)點(diǎn)上，通過比較版本號就可以知道哪個節(jié)點(diǎn)上的數(shù)據(jù)是最新的。

如果用比較時間戳的方式來解決這個問題。這個方法理論上可行，但實(shí)際上非常難實(shí)現(xiàn)，因?yàn)樗蠹荷系拿總€節(jié)點(diǎn)的時鐘都必須時刻保持同步，這個要求往往非常難達(dá)到。