在前文中，提出了分布式系統（尤其是分布式存儲系統）需要解決的兩個最主要的問題，即資料分片和資料備援，下面這個圖檔（來源）形象生動的解釋了其概念和差別：
其中，資料集A、B屬于資料分片，原始資料被拆分成兩個正交子集分布在兩個節點上。而資料集C屬于資料備援，同一份完整的資料在兩個節點都有存儲。當然，在實際的分布式系統中，資料分片和資料備援一般都是共存的。
本文主要讨論資料分片的三個問題：
（1）如何做資料分片，即如何将資料映射到節點
（2）資料分片的特征值，即按照資料中的哪一個屬性（字段）來分片
（3）資料分片的中繼資料的管理，如何保證中繼資料伺服器的高性能、高可用，如果是一組伺服器，如何保證強一緻性
所謂分布式系統，就是利用多個獨立的計算機來解決單個節點（計算機）無法處理的存儲、計算問題，這是非常典型的分而治之的思想。每個節點隻負責原問題（即整個系統需要完成的任務）的一個子集，那麼原問題如何拆分到多個節點？在分布式存儲系統中，任務的拆分即資料分片。
何為資料分片（segment，fragment， shard， partition），就是按照一定的規則，将資料集劃分成互相獨立、正交的資料子集，然後将資料子集分布到不同的節點上。注意，這裡提到，資料分片需要按照一定的規則，不同的分布式應用有不同的規則，但都遵循同樣的原則：按照最主要、最頻繁使用的通路方式來分片。
本文位址：http://www.cnblogs.com/xybaby/p/7076731.html
首先介紹三種分片方式：hash方式，一緻性hash（consistent hash），按照資料範圍（range based）。對于任何方式，都需要思考以下幾個問題：
具體如何劃分原始資料集？
當原問題的規模變大的時候，能否通過增加節點來動态适應？
當某個節點故障的時候，能否将該節點上的任務均衡的分攤到其他節點？
對于可修改的資料（比如資料庫資料），如果某節點資料量變大，能否以及如何将部分資料遷移到其他負載較小的節點，及達到動态均衡的效果？
中繼資料的管理（即資料與實體節點的對應關系）規模？中繼資料更新的頻率以及複雜度？
為了後面分析不同的資料分片方式，假設有三個實體節點，編号為N0， N1， N2；有以下幾條記錄：
R0: {id: 95, name: 'aa', tag:'older'}
R1: {id: 302, name: 'bb',}
R2: {id: 759, name: 'aa',}
R3: {id: 607, name: 'dd', age: 18}
R4: {id: 904, name: 'ff',}
R5: {id: 246, name: 'gg',}
R6: {id: 148, name: 'ff',}
R7: {id: 533, name: 'kk',}
哈希表（散清單）是最為常見的資料結構，根據記錄（或者對象）的關鍵值将記錄映射到表中的一個槽（slot），便于快速通路。絕大多數程式設計語言都有對hash表的支援，如python中的dict， C++中的map，Java中的Hashtable， Lua中的table等等。在哈希表中，最為簡單的散列函數是 mod N（N為表的大小）。即首先将關鍵值計算出hash值（這裡是一個整型），通過對N取餘，餘數即在表中的位置。
資料分片的hash方式也是這個思想，即按照資料的某一特征（key）來計算哈希值，并将哈希值與系統中的節點建立映射關系,進而将哈希值不同的資料分布到不同的節點上。
我們選擇id作為資料分片的key，那麼各個節點負責的資料如下：
由此可以看到，按照hash方式做資料分片，映射關系非常簡單；需要管理的中繼資料也非常之少，隻需要記錄節點的數目以及hash方式就行了。
但hash方式的缺點也非常明顯：當加入或者删除一個節點的時候，大量的資料需要移動。比如在這裡增加一個節點N3，是以hash方式變為了mod 4，資料的遷移如下：
在這種方式下，是不滿足單調性（Monotonicity）的：如果已經有一些内容通過哈希分派到了相應的緩沖中，又有新的緩沖加入到系統中，哈希的結果應能夠保證原有已配置設定的内容可以被映射到原有的或者新的緩沖中去，而不會被映射到舊的緩沖集合中的其他緩沖區。
在工程中，為了減少遷移的資料量，節點的數目可以成倍增長，這樣機率上來講至多有50%的資料遷移。
hash方式還有一個缺點，即很難解決資料不均衡的問題。有兩種情況：原始資料的特征值分布不均勻，導緻大量的資料集中到一個實體節點上；第二，對于可修改的記錄資料，單條記錄的資料變大。在這兩種情況下，都會導緻節點之間的負載不均衡，而且在hash方式下很難解決。
一緻性hash是将資料按照特征值映射到一個首尾相接的hash環上，同時也将節點（按照IP位址或者機器名hash）映射到這個環上。對于資料，從資料在環上的位置開始，順時針找到的第一個節點即為資料的存儲節點。這裡仍然以上述的資料為例，假設id的範圍為［0， 1000］，N0， N1， N2在環上的位置分别是100， 400， 800，那麼hash環示意圖與資料的分布如下：
可以看到相比于上述的hash方式，一緻性hash方式需要維護的中繼資料額外包含了節點在環上的位置，但這個資料量也是非常小的。
一緻性hash在增加或者删除節點的時候，受到影響的資料是比較有限的，比如這裡增加一個節點N3，其在環上的位置為600，是以，原來N2負責的範圍段（400， 800］現在由N3（400， 600] N2(600, 800]負責，是以隻需要将記錄R7(id:533) 從N2,遷移到N3:
不難發現一緻性hash方式在增删的時候隻會影響到hash環上相鄰的節點，不會發生大規模的資料遷移。
但是，一緻性hash方式在增加節點的時候，隻能分攤一個已存在節點的壓力；同樣，在其中一個節點挂掉的時候，該節點的壓力也會被全部轉移到下一個節點。我們希望的是“一方有難，八方支援”，是以需要在增删節點的時候，已存在的所有節點都能參與響應，達到新的均衡狀态。
是以，在實際工程中，一般會引入虛拟節點（virtual node）的概念。即不是将實體節點映射在hash換上，而是将虛拟節點映射到hash環上。虛拟節點的數目遠大于實體節點，是以一個實體節點需要負責多個虛拟節點的真實存儲。操作資料的時候，先通過hash環找到對應的虛拟節點，再通過虛拟節點與實體節點的映射關系找到對應的實體節點。
引入虛拟節點後的一緻性hash需要維護的中繼資料也會增加：第一，虛拟節點在hash環上的問題，且虛拟節點的數目又比較多；第二，虛拟節點與實體節點的映射關系。但帶來的好處是明顯的，當一個實體節點失效是，hash環上多個虛拟節點失效，對應的壓力也就會發散到多個其餘的虛拟節點，事實上也就是多個其餘的實體節點。在增加實體節點的時候同樣如此。除此之外，可以根據實體節點的性能來調整每一個實體節點對于虛拟節點的數量，充分、合理利用資源。
工程中，Dynamo、Cassandra都使用了一緻性hash算法，且在比較高的版本中都使用了虛拟節點的概念。在這些系統中，需要考慮綜合考慮資料分布方式和資料副本，當引入資料副本之後，一緻性hash方式也需要做相應的調整， 可以參加cassandra的相關文檔。
簡單來說，就是按照關鍵值劃分成不同的區間，每個實體節點負責一個或者多個區間。其實這種方式跟一緻性hash有點像，可以了解為實體節點在hash環上的位置是動态變化的。
還是以上面的資料舉例，三個節點的資料區間分别是N0(0, 200]， N1(200, 500]， N2(500, 1000]。那麼資料分布如下：
注意，區間的大小不是固定的，每個資料區間的資料量與區間的大小也是沒有關系的。比如說，一部分資料非常集中，那麼區間大小應該是比較小的，即以資料量的大小為片段标準。在實際工程中，一個節點往往負責多個區間，每個區間成為一個塊（chunk、block），每個塊有一個門檻值，當達到這個門檻值之後就會分裂成兩個塊。這樣做的目的在于當有節點加入的時候，可以快速達到均衡的目的。
不知道讀者有沒有發現，如果一個節點負責的資料隻有一個區間，range based與沒有虛拟節點概念的一緻性hash很類似；如果一個節點負責多個區間，range based與有虛拟節點概念的一緻性hash很類似。
range based的中繼資料管理相對複雜一些，需要記錄每個節點的資料區間範圍，特别單個節點對于多個區間的情況。而且，在資料可修改的情況下，如果塊進行分裂，那麼中繼資料中的區間資訊也需要同步修改。
range based這種資料分片方式應用非常廣泛，比如MongoDB, PostgreSQL， HDFS
在這裡對三種分片方式（應該是四種，有沒有virtual node的一緻性hash算兩種）進行簡單總結，主要是針對提出的幾個問題：
映射難度
中繼資料
節點增删
資料動态均衡
hash方式
簡單
非常簡單，幾乎不用修改
需要遷移的資料比較多
不支援
consistent hash
without virtual node
比較簡單，取決于節點規模，幾乎不用修改
增删節點的時候隻影響hash環上相鄰節點，但不能使所有節點都參與資料遷移過程
consistent hash
with virtual node
中等
稍微複雜一些，主要取決于虛拟節點規模，很少修改
需要遷移的資料比較少，且所有節點都能貢獻部分資料
若支援（修改虛拟節點與實體節點映射關系）
range based
較為複雜
取決于每個塊的大小，一般來說規模較大；且修改頻率較高
支援，且比較容易
上面的資料動态均衡，值得是上述問題的第4點，即如果某節點資料量變大，能否以及如何将部分資料遷移到其他負載較小的節點
上面的三種方式都提到了對資料的分片是基于關鍵值、特征值的。這個特征值在不同的系統中有不同的叫法，比如MongoDB中的sharding key， Oracle中的Partition Key，不管怎麼樣，這個特征值的選擇都是非常非常重要的。
那麼。怎麼選擇這個特征值呢？《Distributed systems for fun and profit》給出了言簡意赅的标準：
based on what you think the primary access pattern will be
大概翻譯為：基于最常用的通路模式。這裡的通路是廣義的，包括對資料的增删改查。比如上面的列子，我們選擇“id”作為分片的依據，那麼就是預設對的資料增删改查都是通過“id”字段來進行的。
如果在應用中，大量的資料操作都是通過這個特征值進行，那麼資料分片就能提供兩個額外的好處：
（1）提升性能和并發，操作被分發到不同的分片，互相獨立
（2）提升系統的可用性，即使部分分片不能用，其他分片不會受到影響
如果大量操作并沒有使用到特征值，那麼就很麻煩了。比如在本文的例子中，如果用name去查詢，而中繼資料記錄的是如何根據按照id映射資料位置，那就尴尬了，需要到多有分片都去查一下，然後再做一個聚合！
另外一個問題，如果以單個字段為特征值（如id），那麼不管按照什麼分布方式，在多條資料擁有相同的特征值（如id）的情況下，這些資料一定都會分布到同一個節點上。在這種情況下有兩個問題，一是不能達到節點間資料的均衡，二是如果資料超過了單個節點的存儲能力怎麼辦？關鍵在于，即使按照分布式系統解決問題的正常辦法 -- 增加節點 --也是于事無補的。
在這個時候，單個字段做特征值就不行了，可能得再增加一個字段作為“聯合特征值”，類似資料庫中的聯合索引。比如，資料是使用者的記錄檔，可以使用id和時間戳一起作為hash函數的輸入，然後算出特征值；但在這種情況下，如果還想以id為查詢關鍵字來查詢，那就得周遊所有節點了。
是以說沒有最優的設計，隻有最符合應用需求的設計。
下面以MongoDB中的sharding key為例，解釋特征值選擇的重要性以及對資料操作的影響。如果有資料庫操作基礎，即使沒有使用過MongoDB，閱讀下面的内容應該也沒有問題。
關于MongoDB Sharded cluster，之前也寫過一篇文章《通過一步步建立sharded cluster來認識mongodb》，做了簡單介紹。在我的工作場景中，除了聯合查詢（join）和事務，MongoDB的使用和Mysql還是比較相似的，特别是基本的CRUD操作、資料庫索引。MongoDb中，每一個分片稱為一個shard，分片的特征值稱為sharding key，每個資料稱之為一個document。選擇适合的字段作為shardingkey非常重要，why？
前面也提到，如果使用非sharding key去通路資料，那麼中繼資料伺服器（或者中繼資料緩存伺服器，後面會講解這一部分）是沒法知道對應的資料在哪一個shard上，那麼該通路就得發送到所有的shard，得到所有shard的結果之後再做聚合，在mongoDB中，由路由節點mongos（緩存有中繼資料資訊）做資料聚合。對于資料讀取（R： read or retrieve），通過同一個字段擷取到多個資料，是沒有問題的，隻是效率比較低而已。對于資料更新，如果隻能更新一個資料，那麼在哪一個shard上更新呢，似乎都不對，這個時候，MongoDB是拒絕的。對應到MongoDB（MongoDD3.0）的指令包括但不限于：
findandmodify：這個指令隻能更新一個document，是以查詢部分必須包含sharding key
When using <code>findAndModify</code> in a sharded environment, the <code>query</code> must contain the shard key for all operations against the shard cluster for the sharded collections.
update：這個指令有一個參數multi，預設是false，即隻能更新一個document，此時查詢部分必須包含sharding key
All <code>update()</code> operations for a sharded collection that specify the <code>multi: false</code> option must include theshard key or the <code>_id</code> field in the query specification.
remove：有一個參數JustOne，如果為True，隻能删除一個document，也必須使用sharidng key
另外，熟悉sql的同學都知道，在資料中索引中有unique index（唯一索引），即保證這個字段的值在table中是唯一的。mongoDB中，也可以建立unique index，但是在sharded cluster環境下，隻能對sharding key建立unique index，道理也很簡單，如果unique index不是sharidng key，那麼插入的時候就得去所有shard上檢視，而且還得加鎖。
接下來，讨論分片到shard上的資料不均的問題，如果一段時間内shardkey過于集中（比如按時間增長），那麼資料隻往一個shard寫入，導緻無法平衡叢集壓力。
MongoDB中提供了"range partition"和"hash partition"，這個跟上面提到的分片方式 hash方式， ranged based不是一回事兒，而是指對sharding key處理。MongoDB一定是ranged base分片方式,docuemnt中如是說：
MongoDB partitions data in the collection using ranges of shard key values. Each range defines a non-overlapping range of shard key values and is associated with a chunk.
那麼什麼是"range partition"和"hash partition"，官網的一張圖很好說明了二者的差別：
上圖左是range partition，右是hash partition。range partition就是使用字段本身作為分片的邊界，比如上圖的x；而hash partition會将字段重新hash到一個更大、更離散的值域區間。
hash partition的最大好處在于保證資料在各個節點上的均勻分布（這裡的均勻指的是在寫入的時候就均勻，而不是通過MongoDB的balancing功能）。比如MongoDB中預設的_id是objectid，objectid是一個12個位元組的BSON類型，前4個位元組是機器的時間戳，那麼如果在同一時間大量建立以ObjectId為_id的資料 會配置設定到同一個shard上，此時若将_id設定為hash index 和 hash sharding key，就不會有這個問題。
當然，hash partition相比range partition也有一個很大的缺點，就是範圍查詢的時候效率低！是以到底選用hash partition還是range partition還得根據應用場景來具體讨論。
最後得知道，sharding key一旦標明，就無法修改（Immutable）。如果應用必須要修改sharidng key，那麼隻能将資料導出，建立資料庫并建立新的sharding key，最後導入資料。
在上面讨論的三種資料分片分式中，或多或少都會記錄一些中繼資料：資料與節點的映射關系、節點狀态等等。我們稱記錄中繼資料的伺服器為中繼資料伺服器（metaserver），不同的系統叫法不一樣，比如master、configserver、namenode等。
中繼資料伺服器就像人類的大腦，一隻手不能用了還沒忍受，大腦不工作整個人就癱瘓了。是以，中繼資料伺服器的高性能、高可用，要達到這兩個目标，中繼資料伺服器就得高可擴充 -- 以此應對中繼資料的增長。
中繼資料的高可用要求中繼資料伺服器不能成為故障單點（single point of failure），是以需要中繼資料伺服器有多個備份，并且能夠在故障的時候迅速切換。
有多個備份，那麼問題就來了，怎麼保證多個備份的資料一緻性？
多個副本的一緻性、可用性是CAP理論讨論的範疇，這裡簡單介紹兩種方案。第一種是主從同步，首先選出主伺服器，隻有主伺服器提供對外服務，主伺服器将中繼資料的變更資訊以日志的方式持久化到共享存儲（例如nfs），然後從伺服器從共享存儲讀取日志并應用，達到與主伺服器一緻的狀态，如果主伺服器被檢測到故障（比如通過心跳），那麼會重新選出新的主伺服器。第二種方式，通過分布式一緻性協定來達到多個副本間的一緻，比如大名鼎鼎的Paxos協定，以及工程中使用較多的Paxos的特化版本 -- Raft協定，協定可以實作所有備份均可以提供對外服務，并且保證強一緻性。
HDFS中，中繼資料伺服器被稱之為namenode，在hdfs1.0之前，namenode還是單點，一旦namenode挂掉，整個系統就無法工作。在hdfs2.0，解決了namenode的單點問題。
上圖中NN即NameNode， DN即DataNode（即實際存儲資料的節點）。從圖中可以看到， 兩台 NameNode 形成互備，一台處于 Active 狀态，為主 NameNode，另外一台處于 Standby 狀态，為備 NameNode，隻有主 NameNode 才能對外提供讀寫服務。
Active NN與standby NN之間的資料同步通過共享存儲實作，共享存儲系統保證了Namenode的高可用。為了保證中繼資料的強一緻性，在進行準備切換的時候，新的Active NN必須要在确認中繼資料完全同步之後才能繼續對外提供服務。
另外，Namenode的狀态監控以及準備切換都是Zookeeper叢集負責，在網絡分割（network partition）的情況下，有可能zookeeper認為原來的Active NN挂掉了，選舉出新的ActiveNN，但實際上原來的Active NN還在繼續提供服務。這就導緻了“雙主“或者腦裂（brain-split）現象。為了解決這個問題，提出了fencing機制，也就是想辦法把舊的 Active NameNode 隔離起來，使它不能正常對外提供服務。具體參見這篇文章。
MongoDB中，中繼資料伺服器被稱為config server。在MongoDB3.2中，已經不再建議使用三個鏡像(Mirrored)MongoDB執行個體作為config server，而是推薦使用複制集（replica set）作為config server，此舉的目的是增強config server的一緻性，而且config sever中mongod的數目也能從3個達到replica set的上線（50個節點），進而提高了可靠性。
在MongoDB3.0及之前的版本中，中繼資料的讀寫按照下面的方式進行：
When writing to the three config servers, a coordinator dispatches the same write commands to the three config servers and collects the results. Differing results indicate an inconsistent writes to the config servers and may require manual intervention.
MongoDB的官方文檔并沒有詳細解釋這一過程，不過在stackexchange上，有人指出這個過程是兩階段送出。
MongoDB3.2及之後的版本，使用了replica set config server，在《CAP理論與MongoDB一緻性、可用性的一些思考》文章中，詳細介紹了replica set的write concern、read concern和read references，這三個選項會影響到複制集的一緻性、可靠性與讀取性能。在config server中，使用了WriteConcern：Majority；ReadConcern：Majority；ReadReferences：nearest。
即使中繼資料伺服器可以由一組實體機器組成，也保證了副本集之間的一緻性問題。但是如果每次對資料的請求都經過中繼資料伺服器的話，中繼資料伺服器的壓力也是非常大的。很多應用場景，中繼資料的變化并不是很頻繁，是以可以在通路節點上做緩存，這樣應用可以直接利用緩存資料進行資料讀寫，減輕中繼資料伺服器壓力。
在這個環境下，緩存的中繼資料必須與中繼資料伺服器上的中繼資料一緻，緩存的中繼資料必須是準确的，未過時的。相反的例子是DNS之類的緩存，即使使用了過期的DNS緩存也不會有太大的問題。
怎麼達到緩存的強一緻性呢？比較容易想到的辦法是當metadata變化的時候立即通知所有的緩存伺服器（mongos），但問題是通信有延時，不可靠。
解決不一緻的問題，一個比較常見的思路是版本号，比如網絡通信，通信協定可能會發生變化，通信雙方為了達成一緻，那麼可以使用版本号。在緩存一緻性的問題上，也可以使用版本号，基本思路是請求的時候帶上緩存的版本号，路由到具體節點之後比較實際資料的版本号，如果版本号不一緻，那麼表示緩存資訊過舊，此時需要從中繼資料伺服器重新拉取中繼資料并緩存。在MongoDB中，mongos緩存上就是使用的這種辦法。
另外一種解決辦法，就是大名鼎鼎的lease機制 -- “An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency”，lease機制在分布式系統中使用非常廣泛，不僅僅用于分布式緩存，在很多需要達成某種約定的地方都大顯身手，在《分布式系統原理介紹》中，對lease機制有較為詳細的描述，下面對lease機制進行簡單介紹。
既然，Lease機制提出的時候是為了解決分布式存儲系統中緩存一緻性的問題，那麼首先來看看Lease機制是怎麼保證緩存的強一緻性的。注意，為了友善後文描述，在本小節中，我們稱中繼資料伺服器為伺服器，緩存伺服器為用戶端。
要點：
伺服器向所有用戶端發送緩存資料的同時，頒發一個lease，lease包含一個有限期（即過期時間）
lease的含義是：在這個有效期内，伺服器保證中繼資料不會發生變化
是以用戶端在這個有效期内可以放心大膽的使用緩存的中繼資料，如果超過了有效期，就不能使用資料了，就得去伺服器請求。
如果外部請求修改伺服器上的中繼資料（中繼資料的修改一定在伺服器上進行），那麼伺服器會阻塞修改請求，直到所有已頒發的lease過期，然後修改中繼資料，并将新的中繼資料和新的lease發送到用戶端
如果中繼資料沒有發生變化，那麼伺服器也需要在之前已頒發的lease到期之間，重新給用戶端頒發新的lease（隻有lease，沒有資料）
在Lease論文的标題中，提到了“Fault-Tolerant”，那麼lease是怎麼做到容錯的呢。關鍵在于，隻要伺服器一旦發出資料和lease，不關心用戶端是否收到資料，隻要等待lease過期，就可以修改中繼資料；另外，lease的有效期通過過期時間（一個時間戳）來辨別，是以即使從伺服器到用戶端的消息延時到達、或者重複發送都是沒有關系的。
不難發現，容錯的前提是伺服器與用戶端的時間要一緻。如果伺服器的時間比用戶端的時間慢，那麼用戶端收到lease之後很快就過期了，lease機制就發揮不了作用；如果伺服器的時間比用戶端的時間快，那麼就比較危險，因為用戶端會在伺服器已經開始更新中繼資料的時候繼續使用緩存，工程中，通常将伺服器的過期時間設定得比用戶端的略大，來解決這個問題。為了保持時間的一緻，最好的辦法是使用NTP（Network Time Protocol）來保證時鐘同步。
Lease機制的本質是頒發者授予的在某一有效期内的承諾，承諾的範圍是非常廣泛的：比如上面提到的cache；比如做權限控制，例如當需要做并發控制時，同一時刻隻給某一個節點頒發lease，隻有持有lease的節點才可以修改資料；比如身份驗證，例如在primary-secondary架構中，給節點頒發lease，隻有持有lease的節點才具有primary身份；比如節點的狀态監測，例如在primary-secondary架構中監測primary是否正常，這個後文再詳細介紹。
工程中，lease機制也有大量的應用：GFS中使用Lease确定Chuck的Primary副本, Lease由Master節點頒發給primary副本，持有Lease的副本成為primary副本。chubby通過paxos協定實作去中心化的選擇primary節點，然後Secondary節點向primary節點發送lease，該lease的含義是：“承諾在lease時間内，不選舉其他節點成為primary節點”。chubby中，primary節點也會向每個client節點頒發lease。該lease的含義是用來判斷client的死活狀态，一個client節點隻有隻有合法的lease，才能與chubby中的primary進行讀寫操作。
本文主要介紹分布式系統中的分片相關問題，包括三種分布方式：hash、一緻性hash、range based，以及各自的優缺點。分片都是按照一定的特征值來進行，特征值應該從應用的使用場景來選取，并結合MongoDB展示了特征值（mongodb中的sharding key）對資料操作的影響。分片資訊（即中繼資料）需要專門的伺服器存儲，中繼資料伺服器是分布式存儲系統的核心，是以需要提到其可用性和可靠性，為了減輕中繼資料伺服器的壓力，分布式系統中，會在其他節點緩存中繼資料，緩存的中繼資料又帶來了一緻性的挑戰，由此引入了Lease機制。
劉傑:《分布式系統原理介紹》
Distributed systems for fun and profit
Wiki：Consistent_hashing
Hadoop NameNode 高可用 (High Availability) 實作解析
CAP理論與MongoDB一緻性、可用性的一些思考
Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency
本文版權歸作者xybaby（博文位址：http://www.cnblogs.com/xybaby/）所有，歡迎轉載和商用，請在文章頁面明顯位置給出原文連結并保留此段聲明，否則保留追究法律責任的權利，其他事項，可留言咨詢。