雲端儲存的故事——中繼資料歸來

中繼資料歸來

莫華楓

雲端儲存體服務是雲端運算的重要組成部分。技術上，雲端儲存屬於大型分布式線上儲存範疇。雲端儲存是一大類特殊的共用儲存。作為提供儲存資源的服務，雲端儲存需要保證使用者存放的資料可靠，不丟失。同時，雲端儲存必須確保即時線上，任何宕機都會給使用者造成損失。因而，雲端儲存的基本要求是高可靠和高可用。此外，雲端儲存是海量資料的儲存，規模巨大。而且，出於成本和現金流量的考慮，雲端儲存的叢集規模必須隨著使用者資料量的不斷增加而擴充。雲端儲存的架構，設計和技術運用都是圍繞這四個基本要求展開。反之，無論多麼漂亮先進的技術，只要可能影響這些目標的實現，都不能應用於雲端儲存。

在我開始接觸儲存的時候，一致性雜湊（以及著名的Dynamo）是非常熱門的技術。技術上一致性雜湊很漂亮，簡潔，並且高效。但在實際應用中，卻是另一種表現。本文將對集中式的中繼資料存放區方案和一致性雜湊作對比分析，以期說明中繼資料是更加適合雲端儲存的選擇。

1. Object Storage Service，Block Storage

實用的雲端儲存可以分作兩類：Object Storage Service和Block Storage。Object Storage Service儲存是地道的資料倉儲，僅僅存放key/value資料：使用者有一個資料對象，需要儲存起來，他就給這個對象起一個名字（key），然後將對象連同名字一起存放入Object Storage Service。當需要的時候，用這個名字作為key，向儲存系統索要。而Object Storage Service系統必須在需要的時候將資料返還給使用者，除非使用者已將此資料從儲存系統中刪除。

Block Storage則是充當作業系統底下的塊裝置（籠統地說，就是磁碟），供系統使用。Block Storage實際上就是一種SAN（Storage Attach Network），將叢集的儲存空間分配給使用者，掛載到作業系統，作為磁碟使用。因為Block Storage需要類比磁碟的行為，因此必須確保低延遲。

儘管兩種雲端儲存有完全不同的目標、用途和特性，但在分布式儲存基本特性方面都面臨著相同的問題，這裡的討論對兩者都有意義。為了簡便起見，這裡只討論Object Storage Service的情況。但很多內容和結論可以外推到Block Storage。

2. 儲存的基礎

雲端儲存功能非常簡單，儲存使用者的資料而已。但簡單歸簡單，幾個要點還是需要做的。當使用者將一個key-value對上傳至儲存時，儲存系統必須找合適的伺服器，儲存資料。通常會儲存在多台伺服器上，以防止資料丟失。這叫多副本。

於是，一個關鍵的問題就是如何選擇存放資料的伺服器。伺服器的選擇是很有技術含量的事，需要兼顧到幾個要點：首先，資料必須在伺服器之間平衡。不能把資料集中到少數幾台伺服器，造成一部分伺服器撐死，而另一部分餓死。其次，在使用者讀取資料時，可以方便快捷定位。隨後，滿足雲端儲存體服務高可靠高可用大規模的特點。最後，儘可能簡單。

於是，對於每個對象，都有一個key到資料存放區位置的映射: key->pos。映射方式很多，最直接的，就是將每一個對象的key->pos資料對儲存下來。這些資料通常被稱為＂中繼資料＂。

但還有一些更巧妙的方式：根據key的特徵，將key空間劃分成若干分組，並將這些分組對應到不同的儲存節點上。這種方式可以籠統地成為”Sharding"。如此，可以直接按照一個簡單規則定位到伺服器。常用的分組方式之一是按key的區間劃分，比如a開頭的是一組，b開頭的是一組等等。而另一種更具＂現代感＂的分組方式，就是對key雜湊後模數。雜湊方案實際上就是雜湊表的自然延伸，將桶分布到多台伺服器中。

這兩大類映射方式實質上是在不同的粒度上進行映射。＂中繼資料＂在對象粒度上，而sharding則是在一組對象的粒度。這兩種不同的粒度，決定了它們有著完全不同的特性。也決定了它們在實際應用中的表現。

3. 中繼資料和一致性雜湊

於是，在雲端儲存方案中產生了兩大流派：中繼資料模型和Sharding模型。而Sharding模型中，一致性雜湊最為流行。一致性雜湊本身很難直接用作實際使用，進而產生了很多衍生方案，其中包括著名的"Dynamo"。這裡用“一致性雜湊方案”指代所有基於一致性雜湊的設計。

中繼資料方案是對象層級的key->pos映射，也就是一個會無休止增長的＂map＂。每多一個對象，就會多一條中繼資料。通常會將中繼資料儲存在一組資料庫中，方便檢索和查詢。中繼資料方案沒有什麼特別的地方，其核心是中繼資料存放區部分。這部分設計的好壞，關係到系統整體的特性。關於中繼資料存放區的設計不是本文的重點，本文將集中探討中繼資料方案和一致性雜湊方案的比較。

標準的一致性雜湊模型是對key進行雜湊運算，然後投射到一個環形的數值空間上。與此同時，對節點（儲存伺服器）進行編碼，然後也做雜湊運算，並投射到雜湊環上。理論上，只要雜湊演算法合適，節點可以均勻地分布在雜湊環上。節點根據自身在雜湊環上的位置，佔據一個雜湊值區間，比如從本節點到下一個節點間的區間。所有落入這個區間的key，都儲存到該節點上。

在這個模型中，key到資料存放區邏輯位置的映射不通過儲存，而是通過演算法直接得到。但是，邏輯位置（雜湊環上的位置）到物理位置（節點）的轉換無法直接得到。標準的做法是任選一個節點，然後順序尋找目標節點，或者採用二分法在節點之間跳轉尋找。這種尋找方式在實際的儲存系統中是無法忍受的。所以，實用的儲存系統往往採用的是一個混合模型（暫且稱之為“混合方案”）：系統維護一個雜湊區間->節點的映射表。這個映射本質上也是一種中繼資料，但是它是大粒度的中繼資料，更像是一個路由表。由於粒度大，變化很少，所以即便用文字檔都可以。這個映射表也需要多份，通常可以存放在入口伺服器上，也可以分散到所有的儲存節點上，關鍵是保持一致即可，這相對容易。

一致性雜湊解決了標準雜湊表改變大小時需要重新計算，並且遷移所有資料的問題，只需遷移被新加節點佔據的雜湊區間所包含的資料。但是，隨著新節點的加入，資料量的分布會變得不均勻。為瞭解決這個問題，包括Dynamo在內的諸多模型，都採用了＂虛擬結點＂的方案：將一個節點分成若干虛擬節點。當節點加入系統時，把虛擬節點分散到雜湊環上，如此可以更加＂均勻地＂添加一個節點。

一致性雜湊及其衍生方案，將資料按一定規則分區，按一定規則將分區後的資料對應到相應的儲存伺服器上。因此，它只需要維護一個演算法，或者一個簡單的映射表，便可直接定位元據。更加簡單，並且由於少了查詢中繼資料，效能上也更有優勢。

但是，這隻是理論上的。

如果我們只考慮儲存的功能（get，put，delete），一致性雜湊非常完美。但實際情況是，真正主宰雲端儲存架構的，是那些非功能性需求：

1、 大規模和擴充性

2、 可靠性和一致性

3、 可用性和可管理

4、 效能

在實際的雲端儲存系統中，非功能需求反而主導了架構和設計。並且對key-pos映射的選擇起到決定性的作用。

4 規模和擴充

首先，雲端儲存最明顯的特點是規模巨大。對於一個公用雲端儲存服務，容納使用者資料是沒有限度的。不可能以＂容量已滿＂作為理由，拒絕使用者存放資料。因此，雲端儲存是“規模無限”的。意思就是說，雲端儲存系統，必須保證任何時候都能夠隨意擴容，而不會影響服務。

另一方面，雲端儲存作為服務，都是由小到大。一開始便部署幾千台伺服器，幾十P的容量，毫無意義。資源會被閑置而造成浪費，對成本和現金流量產生很大的負面作用。通常，我們只會部署一個小規模的系統，滿足初始的容量需求。然後，根據需求增長的情況，逐步擴容。

於是，雲端儲存系統必須是高度可擴充的。

面對擴充，中繼資料方案沒有什麼困難。當節點增加時，系統可以更多地將新來的寫請求引導到新加入的節點。合適的調度平衡策略可以確保系統平衡地使用各節點的儲存空間。

但對於一致性雜湊和它的衍生方案而言，卻麻煩很多。原始的雜湊表一旦需要擴容，需要rehash。在基於雜湊的分布式儲存系統中，這就意味著所有資料都必須重新遷移一遍。這當然無法忍受的。一致性雜湊的出現，便可以解決此問題。由於對象和伺服器都映射到雜湊環上，當新節點加入後，同樣會映射到雜湊環上。原來的區段會被新節點截斷，新加入的節點，會佔據被切割出來的雜湊值區間。為了完成這個轉換，這部分資料需要遷移到新伺服器上。相比原始的雜湊，一致性雜湊只需要傳輸被新伺服器搶走的那部分資料。

但是終究需要進行資料移轉。資料移轉並非像看上去那樣，僅僅是從一台伺服器向另一台伺服器複製資料。雲端儲存是一個線上系統，資料移轉不能影響系統的服務。但遷移資料需要時間，為了確保資料訪問的延續性，在遷移開始時，寫入操作被引導到目標伺服器，而源節點的待遷移部分切換至唯讀狀態。與此同時，開始從源節點遷移資料。當使用者試圖讀取遷移範圍內的資料時，需要嘗試在源和目標節點分別讀取。這種單寫雙讀的模式可以保證服務不受影響。但是，必須控制資料移轉的速率。如果遷移操作將磁碟吞吐能力跑滿，或者網路頻寬耗盡，服務必然受到影響。

另一個問題是，除非成倍地增加節點，否則會存在資料不平衡的問題。為了平衡資料，需要遷移更多的資料，每台節點都需要遷出一些，以確保每個節點的資料量都差不多。虛擬節點的引入便是起到這個作用。於是實際的資料移轉量同增加的容量數成正比，係數是當前儲存系統的空間使用率。

於是，一個1P的系統，三副本，70%的消耗，擴容200T，那麼需要遷移大約140T*3=420T的資料，才能使資料存放區量得到平衡。如果使用現在常用的儲存伺服器（2T*12），需要新增21台。如果它們都並發起來參與遷移，單台遷移速率不超過50MBps，那麼這次擴容所需的時間為420T/(50M*21)=400000秒，大約4.6天。這是理想狀況，包括軟硬體異常，使用者訪問壓力，遷移後的檢驗等情況，都會延長遷移時間。很可能十天半月泡在這些任務上。而在資料移轉完成，老伺服器的儲存空間回收出來之前，實際上並未擴容。那麼萬一擴容實在系統空間即將耗盡時進行，（別說這事不會碰到，一個懶散的供貨商，或者廠家被水淹，都可能讓這種事情發生。雲端運算什麼事都會遇到），那麼很可能會因為來不及完成擴容而使系統停服。雲端儲存，特別是公用雲端儲存，擴容必須是快速而便捷的。

更複雜的情況是遷移過程中出錯，硬體失效等異常情況的處理過程會很複雜，因為此時資料分布處於一種中間狀態，後續處理必須確保系統資料安全一致。

系統的擴容規模越大，困難程度越大。當系統有100P的規模（很多系統宣稱可以達到的規模），而使用者資料增長迅猛（公用雲端儲存有明顯的馬太效應，規模越大，增長越快），在幾百上千台伺服器之間遷移成P的資料，是多麼駭人的情境。

資料移轉會消耗網路頻寬，吃掉磁碟負載，攪亂伺服器的cache等等，都是雲端儲存的大忌，能不做盡量不做。

中繼資料方案一般情況下不需要做遷移。遷移只有儲存伺服器新舊更替，或者租借的伺服器到期歸還時進行。由於資料對象可以放置在任何節點上，因而可以把一台節點需要遷移的資料分散到其他節點上。並且可以從其他副本那裡多對多並發地傳輸資料。負載被分散到整個叢集，對服務的影響更小，也更快捷。實際上，這個邏輯和資料副本修複是一樣的。

很顯然，相比一致性雜湊方案動不動來回遷移資料的做法，中繼資料方案提供一個動態平衡的機制，可以無需資料移轉，伺服器一旦加入叢集，可以立刻生效，實現平靜地擴容。

5 可靠性和一致性

可靠性（本文特指資料的可靠性，即不遺失資料）無疑是雲端儲存的根本。使用者將資料託付給你，自然不希望隨隨便便地丟失。維持可靠性是雲端儲存最困難的部分。（當然，更難的是在保持高可靠性的前提下確保高可用）。

在任何一個系統中，硬體和軟體都無法保障完全可靠。晶片會被燒毀，電路可能短路，電壓可能波動，老鼠可能咬斷網線，供電可能中斷，軟體會有bug，甚至宇宙射線會干擾寄存器…。作為儲存的核心組件，硬碟反而更加脆弱。在標準的伺服器中，除了光碟機和風扇以外，硬碟是唯一的機電元件。由於存在活動組件，其可靠性不如固態電路，更容易受到外界的幹擾。所以，硬碟時常被看作消耗品。在一個有幾萬塊硬碟的儲存叢集中，每周壞上幾塊硬碟是再尋常不過的事。運氣不好的時候，一天中都可能壞上2、3塊。

因此，只把資料儲存在一塊盤中是無法保障資料可靠的。通常我們都會將資料在不同的伺服器上儲存多份，稱之為“副本”。原則上，副本越多，越可靠。但是，過多的副本會造成儲存成本的增加，並且降低效能，增加維持一致性的難度。一般會保持3副本，是一個比較均衡的數字。

但是，在確定的副本數下，真正對可靠性起到關鍵作用的，是副本丟失後的恢複速度。比如，一個3副本儲存系統中，當一個磁碟損壞後，它所承載的資料對象就只剩2個副本了。在這塊盤修複之前，如果再壞一塊盤，恰巧和尚未修複的盤有共同的資料對象，那麼這些資料就只剩一個副本在支撐著，這是非常危險的狀態。更有甚者，一個3副本的儲存系統，在運行過程中，即便沒有硬碟損壞，總會有一些對象由於種種原因處於兩副本狀態，尚未來得及修複。比如寫入資料時，有一個副本寫完後發現校正碼不對，需要重寫。此時，如果一塊盤損壞了，上面正好有這些2副本的對象。於是，從這一刻開始，這個對象只有1副本。壞盤上的資料被修複之前，另一塊盤包含此對象的硬碟也壞了，那麼資料就丟了。儘管這種機率很小，但是雲端儲存系統是經年累月地運行，大規模加上長時間，任何小機率事件都會發生。而且在實際啟動並執行系統中，很多因素會導致硬碟壽命遠小於理論值，比如機架震動、電源不穩、意外失電、輻射等等。而且，對於成批採購的硬碟，通常都會集中在一段時間內一起進入失效期，多塊磁碟同時損壞的機率會大幅提高。

如果資料修複的速度足夠快，可以搶在另一塊盤損壞之前，修複丟失的副本，那麼資料丟失的機率會大大減小。（嚴格地講，無論修複時間有多短，在修複期間壞第二塊盤的機率始終存在，只是修複時間越短，這個機率越小。關鍵是要讓它小到我們可以接受的程度）。

一致性雜湊方案中，如果將一塊磁碟同一個hash區間一一綁定。因此，資料恢複時，只能先更換壞盤，然後從其他副本處讀取資料，寫入新磁碟。但是，磁碟的持續寫入能力通常也只有50-60MBps。如果是一塊有1.5T資料的硬碟失效，那麼恢複起來至少需要30000秒，將近9個小時。考慮到伺服器的整體負載和網路狀況，時間可能會接近12小時。在這個時間尺度裡，第二塊盤，甚至第三塊盤損壞的機率還是相當大的。而且，硬碟更換的時間取決於機房管理的響應能力，這往往是一個薄弱環節。

如果方案中讓節點同hash區間一一對應，在節點內部，再將資料分散儲存到一塊磁碟中，那麼當需要恢複副本時，節點將損壞的磁碟上的資料對象分散存放到其他磁碟上。這樣，可以先發起修複，從其他副本那裡都到資料，並發地向多個磁碟恢複資料，磁碟的吞吐限制會得到緩解。但問題的解決並不徹底。首先，網路會成為瓶頸。1個千兆網口最多支援到120MBps，這個速率也僅僅比磁碟快一倍，而且實際使用中也不能將頻寬全部用光，否則影響服務，畢竟其他硬碟還是好的，還需要正常工作。原則上可以通過增加網口數量拓寬輸送量，但這增加了網路裝置方面的成本。而且這也僅僅是增加3、4倍的吞吐能力，我們真正需要的是近10倍地縮小恢復。至於光纖，那不是普通公用雲端儲存所能奢望的。即便網路吞吐問題解決了，還有一個更核心的問題。因為資料在節點內部任意分散到各磁碟上，那麼節點就需要維護一個key->磁碟的映射，也就是節點內的局部中繼資料。這個中繼資料需要伺服器自己維護，由於單台伺服器的資源有限，中繼資料的可靠性、可用性和一致性的維持非常麻煩。一套儲存一套中繼資料存放區已經夠麻煩的了，何況每個節點一套中繼資料。一旦這個中繼資料丟失了，這個節點上所有的資料都找不到了。理論上，這個中繼資料丟失了，也不會影響全域，可以利用一致性雜湊演算法到其他副本那裡恢複出丟失的資料。但不得不將原來伺服器上的所有資料都傳輸一遍，這個資料量往往有一二十T，恢複起來更困難。更現實的做法是直接掃描各磁碟，逆向地重建中繼資料。當然，這將是一個漫長的過程，期間整台節點是停用，此間發生的寫入操作還需的事後重新恢複（具體參見本文“可用性”部分）。

副本恢複最快，影響最小的方法就是，不讓資料對象副本綁死在一台節點上，只要資料對象可以存放到任意一台節點，那麼便可以在節點之間做多對多的資料副本恢複。叢集規模越大，速度越快，效果越好。基於中繼資料的方案，每一個對象同節點，乃至硬碟的映射是任意的，在副本恢複方面，有得天獨厚的優勢。而一致性雜湊嚴格地將資料同節點或磁碟綁定，迫使這種並發無法進行。

有一些基於混合方案的衍生方案可以解決一致性雜湊在副本修複速度問題：將雜湊環劃分成若干slot（bucket，或者其他類似的稱謂），數量遠遠大於將來叢集可能擁有的節點數，或磁碟數。（好吧，我們說過規模無限，無限自然不可能，只要足夠大就行了，比如2^32）。slot到節點或者磁碟的映射，通過一個映射表維護。各複本集群中的slot分布互不相同。當一個磁碟損壞時，找出所包含的slot，將這些slot分散到其他節點和磁碟上去，這樣便可以並發地從其他節點以slot為單位恢複副本。在損壞磁碟更換之後，再將一些slot，可以是原來的，也可以是隨意的，遷移到新硬碟，以平衡整體的資料分布。遷移的時候，副本已經恢複，遷移操作的時間壓力就很小了，可以慢慢來，磁碟吞吐的瓶頸也不會有什麼的影響。

但相比之下，中繼資料方案修複副本之後不存在資料移轉這一步，在這方面對象級中繼資料的存在使副本恢複簡單很多。

同資料可靠性相關的一個問題是一致性。一致性問題可以看作可靠性問題的一個部分。因為當各副本的資料版本不一致時，便意味著資料對象的目前的版本是缺少副本的。（實際上，從儲存角度來講，一個資料對象的不同版本，就是不同的資料）。確保一個資料對象的一致性最實用的方法是所謂W+R>N。即N個副本中，一個版本寫入時確保有W個成功，而讀取時確保有R個成功，只要滿足W+R>N的情況，便可以保證始終可以讀到最後寫入成功的版本。

W+R>N的使用有一個問題，需要並發地從所有副本上嘗試讀取資料，然後通過讀取的資料對象版本（或者時間戳記）的比對，以確定是否滿足一致性公式的要求。如果所讀取的資料有幾十上百MB，甚至上G的對象，一口氣讀出所有副本，而最終只取其中一個，著實浪費，系統壓力會整整大上N倍。解決的方法是先做一次預讀，讀出所有副本的版本資訊，進行一致性比對，確定有效副本後，再行資料本身的讀取。

中繼資料方案在一致性上簡單的多。中繼資料為了保證可靠，也會使用多副本。因為中繼資料很小，可以保持更多的副本數，比如5個，甚至7個。如此多的副本，基本上不必擔心其可靠性。重點在於一致性。同樣也是採用W+R>N的策略，但卻將中繼資料讀取和一致性保障在一次訪問中解決。對於資料存放區伺服器而言，任務更多地是在保障每一個副本和版本的完整。

隨著時間的推移，資料會發生退化，有各種原因造成副本的丟失。一致性也是一樣。對於熱資料，經常被訪問，儲存資料出錯很快就會發現。但冷資料需要依靠定期檢查發現錯誤。這個核對工作在中繼資料方案裡，就是比對中繼資料和節點的每個盤上的對象清單，中繼資料儲存的永遠是最新版本，只要不匹配，就可以認定出錯，立刻加以修複。但在一致性雜湊方案中，需要交叉核對一個雜湊區間的三個副本所包含的對象清單，以確定哪個對象是最新副本。然後再修正資料問題。

當一個節點由於種種原因下線，那麼期間的所有寫入操作都無法完成。此時，中繼資料方案處理起來很簡單：另外挑選一台合適的節點，寫入副本，更新相應的中繼資料項後，操作完成，一切太平。

一致性雜湊方案要複雜得多。對於一個雜湊區間的一個副本，被固定在一個節點上。換句話說，一組副本必須存放在特定的一個節點上，不能隨意放置。如果需要定位到其他節點上，必須整區間的遷移。這個特性的結果就是，當這台節點下線後，無法寫入相應的副本，也無法隨意地將副本寫到其他節點上。後續處理有2種方法：1、將副本或者key寫入一個隊列，等節點恢複後，發起修複操作，從其他的副本獲得資料，補上缺失的副本。問題是這個隊列必須有足夠的可靠性，否則待修複key丟失，相應的對象會長時間缺少副本，直到資料一致性檢測發現問題。這會增加一致性檢測的壓力，使得原本就複雜的過程雪上加霜；2、按一定規則寫入其他節點，待恢複後原樣遷移回來。這個方案相對簡單些，但整個調度邏輯比較複雜，涉及到資料節點之間的協調。但是這種點到點的資料恢複，會給暫存伺服器產生壓力，不利於穩定運行。不管哪種方案，資料移轉或者複製都是免不了的。這中間的異常處理，負載控制等都需要花費心思。

中繼資料方案在節點失效時的處理要比一致性雜湊方案單純簡潔的多。節點失效是雲端儲存的常態，處理方式越簡潔越好。在大叢集中，幾個節點同時下線都是很平常的事，一致性雜湊如此複雜的節點失效管理，就是營運的地獄。

6. 可用性和可管理性

可用性在某些方面同可靠性有著共同的解決方案，比如多副本可以消除單點，提高可用性。但是它們在其他方面卻存在著矛盾。當一個副本寫入失敗，從可靠性角度而言，應當設法重試，或者索性告訴使用者寫入失敗。但這樣勢必造成響應變慢，或者可用性降低。（響應變慢超過一個程度後，便會被認為是失敗，不管最終是否成功）。此外，為了保障可靠性的諸多措施，比如副本修複，資料移轉等，會消耗系統資源，從而影響到可用性。

在上面對於可靠性的分析中可以看到，由於副本被綁定在特定節點上，一致性雜湊要確保同中繼資料相當的可靠性的話，不得不放棄一些可用性，將有副本寫入出錯的操作返回失敗。因為中繼資料方案的資料存放區位置沒有限制，對於多數的副本寫入失敗可以通過重選伺服器得到更正。一致性雜湊則無此便利，要麼放棄一定的可用性，要麼承擔可靠性的風險。

根本上而言，一致性雜湊在副本寫入上製造了局部的隱式單點，儘管是短期的或者臨時的，但依舊會對系統產生影響。一個設計良好的分布式系統會盡量地減少單點出現的可能性，這直接關係到系統的持續和瞬時可用性。中繼資料方案可以確保資料分布上不存在任何形式的單點。對於一個對象而言，任何節點都沒有特殊性，這種無差別化才能真正保證消除單點。

在雲端儲存系統中，使用公式R+W>N的地方，便是影響系統可用性的核心要點。可用性和一致性往往是一對冤家。在這個地方，需要向N台伺服器同時發出請求，而最終的有效性取決於伺服器反饋的情況。一般來說，N越大，越容易在確保一致性的前提下，維持可用性。（實際上是取決於X=R+W-N的值，越大越好。這個值表示當X+1個副本下線或丟失後，系統將不能保證臨時的或永久的一致性）。但是，N-R和N-W越小，對可用性的影響越大。如果N=R，那麼只要有一台伺服器下線，會造成系統不可讀取。如果N-R=3，那麼即便是3台伺服器下線，系統還能正確讀取。對於W也一樣。在這裡，一致性和可用性是一對矛盾。當副本數足夠多（N數可以很大），可以很容易地獲得較高的X數。比如N=7,
R=W=5，X=3，N-R=2，N-W=2，意味著即便有2台伺服器下線，也能保證讀寫的有效性，同時確保一致性。

但如果N=3，無論如何也只能讓R=3或者W=3，此時儘管可以獲得X=3的一致性保障層級，但即便一台伺服器下線，也會造成系統不可用。如果R=W=2，可以保證1台伺服器下線，系統還是可用，但一致性保障層級降低到了X=1。

在中繼資料方案中，中繼資料的副本數（N）可以大些，故障和異常造成的副本下線，或者丟失，對系統的可用性和一致性產生的影響很小，對於這類問題的處理的緊迫性會低一些。相反，一致性雜湊的一致性依賴於資料存放區節點，面對大大小小的資料對象，無法使用很多副本，通常都會用3。在這個N數下，無論一致性還是可用性，都很脆弱。

對於可用性而言，最後，也是最重要的一點是營運管理。營運的好壞直接決定了可用性。前文已述，一致性雜湊在一些關鍵的系統維護點上相比中繼資料方案多出不少環節。在同樣營運水平和強度下，一致性雜湊更加容易出現可用性問題。這方面對可用性的影響很難明確地給出量化的評判，但是營運是雲端儲存系統高可用保障的核心，營運的複雜性往往決定了最終9的個數。

現在來看看中繼資料方案的營運特點。中繼資料方案相比標準一致性雜湊方案多出了一個中繼資料存放區系統。中繼資料通常有更多的副本，副本數越多，一致性的維持越發困難。一般的方案都是依賴非同步執行的版本同步機制，儘快同步各副本。但是，為防止同步失效，會定期全面掃描核對所有中繼資料，確保中繼資料不會退化。這個過程伴隨者很大的資料吞吐和計算量。但這個過程是離線操作，並且沒有非常嚴格的時間要求，即便失敗，也不會過多地影響系統的運行。它的時間裕度比較大。中繼資料量不會很大，在合適的演算法下，一致性比對的時間也不會很長，通常不超過2、3小時。並且可以根據需要增減所需的伺服器數量。

一致性雜湊營運的重點則在另一頭。一致性雜湊模型及其各種變形由於需要確保資料平衡，不得不在擴容時進行大範圍的資料移轉。在不影響服務的情況下，遷移速率必須受到限制，導致遷移時間很長。但有時資料移轉的時間要求很高。因為在遷移完成之前，遷移的資料來源所佔的空間還不能回收。此時所添加的空間暫時無法使用。而且資料回收也需要花費時間。在可用空間緊迫的情況下，遷移速度的壓力會很大。一旦遷移過程中出現異常，將會雪上加霜。在長達幾天的資料移轉過程中發生磁碟損壞的可能性非常大，修複操作將迫使資料移轉減速，甚至停止。修複的優先順序更高。遷移操作涉及很多伺服器的並發，協調和控制工作很複雜。而且不同的遷移原因會有不同的遷移策略。再加上各種異常處理，營運管理內容很多，將是非常痛苦的事。隨著規模越來越大，最終可能超出營運能力的極限，無力維持儲存的可用性。

中繼資料方案在絕大多數情況下不會進行資料移轉。少掉這樣一個複雜重載的環節，對於系統維護的壓力會小很多。

因此，儘管中繼資料方案多出了一個中繼資料的儲存叢集，但它相比一致性雜湊方案反而更容易維持可用性。

7. 效能

效能是大多數程式員都關心的東西，往往被放在很高的位置。但在雲端儲存中，效能反倒是層級較低的問題。儲存是io密集型的系統，無論如何最佳化代碼，都不可避免地受到物理裝置的限制。

雲端儲存的效能要點首先在於並發。做好並發，確保所有請求不會相互間阻塞，便可以從大的方面保證效能。中繼資料方案中，中繼資料存取存在大量的並發訪問。每個使用者的資料訪問請求，在這裡會轉化成N個並發請求。系統不得不管理巨大數量的並行作業，並且小心維護並發之間的邏輯關係。傳統上使用的線程池很難滿足需要，不得不採用非同步模型，從而增加開發難度。

一致性雜湊在這方面有自身的優勢。因為N數不大，並發的放大效應相比中繼資料方案要小很多。當然前面也說了，小N數會減小一致性的裕度，也不利於可用性。

雲端儲存效能最佳化另一個重要的要點是，減少一次使用者請求中跨伺服器訪問的次數。跨越網路的訪問必然存在延遲，跨的次數越多，整體延遲越大。同時也會增加網路的負擔。中繼資料方案天生多一次中繼資料檢索操作，因而在這方面處於劣勢。但一致性雜湊在讀取對象時，也沒有好到哪裡去。前面討論一致性的時候已經說過，為了執行W+R>N的邏輯，又不能讀取所有副本，只能採取一次並發預讀操作。這樣一致性雜湊的跨伺服器訪問次數也同中繼資料方案扯平了。只是並發數少一些。這是以降低容錯能力為代價的。

中繼資料在效能方面的主要劣勢是中繼資料的訪問。系統對中繼資料的訪問主要是檢索操作，因此通常會採用資料庫，或者具備檢索功能的資料存放區引擎。這些模組在重載情況下有效能限制。由於副本數多，簡單地擴充伺服器數量代價較大。好在這些部分的最佳化，特別是資料庫最佳化，有很成熟的經驗，花些功夫也是能做好的。

8. 其他

在功能方面，一致性雜湊還有一個不足。儘管一致性雜湊可以實現Object Storage Service的準系統，但儲存服務有時需要提供一些額外的功能，比如列出一個使用者所儲存的對象key清單。如果有中繼資料，那麼這些使用者的資訊可以儲存在中繼資料裡，需要的時候檢索這些資訊即可。但是，在一致性雜湊方案中，所有的key在系統中已經被雜湊，分散到所有伺服器上。如果要獲得使用者的對象清單，那麼就不得不在所有儲存節點上執行相應的檢索操作，想象一下一個幾千，甚至幾萬台節點的儲存叢集，執行一次這樣的操作，會是什麼結果？

對於存放了大量資料對象的使用者，列出對象清單的操作可能沒有什麼直接意義。或許不提供此類功能，使用者也能忍受。但是，另一個使用者相關的問題卻無法迴避。這就是計費。計費就是計算出一個使用者所有的對象所佔據的容量，然後製作成費用清單，提供給計費系統。

計費最簡單的辦法是通過使用者的訪問記錄，累積出來，寫入就加，刪除就減。但是實際沒那麼簡單。對於一個key的覆蓋寫入，那麼必須先扣除原有的對象大小，然後再加上新對象的大小。

更重要的，由於訪問記錄可能出錯或者丟失，這種相對計算方式隨著時間的增長會產生累積誤差。需要定期校準。校準的方式就是統計所有使用者的對象大小，做絕對容量的計算。由於對象大小存放在所有資料存放區節點中，這又是一個恐怖的全系統的資料掃描。同時還必須確保對象屬性的一致性，以免計費出錯。

計費涉及到錢，通常使用者會非常敏感，應當儘可能不出錯。校準需要盡量頻繁。但是全叢集的計費校準代價實在太高，還是應當盡量少做。於是這對矛盾怎麼調和，對於開發營運人員都是個巨大的挑戰。

在中繼資料方案中，計費所需資訊都可以儲存在中繼資料中，計費操作只局限在中繼資料上。中繼資料量少，可以直接將資料dump出來，在額外的伺服器上計算。這種操作相對輕量很多，可以更頻繁地執行，提高使用者賬單的準確性。

9. 總結

經過大體的分析，可以看到在僅考慮雲端儲存功能需求的情況下，一致性雜湊具備簡單高效的優勢。但是，大型的雲端儲存系統的功能不是影響其架構的主要因素。包括規模、可擴充性、可靠性、可用性和一致性等方面的非功能性需求才是雲端儲存需要重點考慮的地方。一致性雜湊及其各種變形方案，在這些方面存在諸多缺陷。儘管每個方面的缺陷並非不可逾越的障礙，往往都可以通過一些設計和營運手段加以解決。但是系統複雜度和營運難度隨之增加。最關鍵的，每個方面的問題整合起來所產生的疊加效應，會輕而易舉地摧垮一個雲端儲存系統。

一般而言，一致性雜湊適合一些有既定規模，不太需要擴充，資料尺寸不大的場合。這些特性意味著一致性雜湊無法很好地適用於大型的雲端儲存系統。中繼資料方案儘管在架構上複雜些，但其優點是靈活。而這種靈活性更加適合雲端儲存的需要。