隨筆檔案

負載平衡策略

Dynamo的負載平衡取決于如何給每臺機器分配虛擬節(jié)點號。由于集群環(huán)境的異構性，每臺物理機器包含多個虛擬節(jié)點。一般有如下兩種分配節(jié)點號的方法：

1. 隨機分配。每臺物理節(jié)點加入時根據(jù)其配置情況隨機分配S個Token(節(jié)點號)。這種方法的負載平衡效果還是不錯的，因為自然界的數(shù)據(jù)大致是比較隨機的，雖然可能出現(xiàn)某段范圍的數(shù)據(jù)特別多的情況（如baidu, sina等域名下的網頁特別多），但是只要切分足夠細，即S足夠大，負載還是比較均衡的。這個方法的問題是可控性較差，新節(jié)點加入/離開系統(tǒng)時，集群中的原有節(jié)點都需要掃描所有的數(shù)據(jù)從而找出屬于新節(jié)點的數(shù)據(jù)，Merkle Tree也需要全部更新；另外，增量歸檔/備份變得幾乎不可能。

2. 數(shù)據(jù)范圍等分+隨機分配。為了解決方法1的問題，首先將數(shù)據(jù)的Hash空間等分為Q = N * S份 (N=機器個數(shù)，S=每臺機器的虛擬節(jié)點數(shù)），然后每臺機器隨機選擇S個分割點作為Token。和方法1一樣，這種方法的負載也比較均衡，且每臺機器都可以對屬于每個范圍的數(shù)據(jù)維護一個邏輯上的Merkle Tree，新節(jié)點加入/離開時只需掃描部分數(shù)據(jù)進行同步，并更新這部分數(shù)據(jù)對應的邏輯Merkle Tree，增量歸檔也變得簡單。該方法的一個問題是對機器規(guī)模需要做出比較合適的預估，隨著業(yè)務量的增長，可能需要重新對數(shù)據(jù)進行劃分。

不管采用哪種方法，Dynamo的負載平衡效果還是值得擔心的。

客戶端緩存及前后臺任務資源分配

客戶端緩存機器信息可以減少一次在DHT中定位目標機器的網絡交互。由于客戶端數(shù)量不可控，這里緩存采用客戶端pull的方式更新，Dynamo中每隔10s或者讀/寫操作發(fā)現(xiàn)緩存信息不一致時客戶端更新一次緩存信息。

Dynamo中同步操作、寫操作重試等后臺任務較多，為了不影響正常的讀寫服務，需要對后臺任務能夠使用的資源做出限制。Dynamo中維護一個資源授權系統(tǒng)。該系統(tǒng)將整個機器的資源切分成多個片，監(jiān)控60s內的磁盤讀寫響應時間，事務超時時間及鎖沖突情況，根據(jù)監(jiān)控信息算出機器負載從而動態(tài)調整分配給后臺任務的資源片個數(shù)。

Dynamo的優(yōu)點

1. 設計簡單，組合利用P2P的各種成熟技術，模塊劃分好，代碼復用程度高。

2. 分布式邏輯與單機存儲引擎邏輯基本隔離。很多公司有自己的單機存儲引擎，可以借鑒Dynamo的思想加入分布式功能。

3. NWR策略可以根據(jù)應用自由調整，這個思想已經被Google借鑒到其下一代存儲基礎設施中。

4. 設計上天然沒有單點，且基本沒有對系統(tǒng)時鐘一致性的依賴。而在Google的單Master設計中，Master是單點，需要引入復雜的分布式鎖機制來解決，且Lease機制需要對機器間時鐘同步做出假設。

Dynamo的缺陷

1. 負載平衡相比單Master設計較不可控；負載平衡策略一般需要預估機器規(guī)模，不能無縫地適應業(yè)務動態(tài)增長。

2. 系統(tǒng)的擴展性較差。由于增加機器需要給機器分配DHT算法所需的編號，操作復雜度較高，且每臺機器存儲了整個集群的機器信息及數(shù)據(jù)文件的Merkle Tree信息，機器最大規(guī)模只能到幾千臺。

3. 數(shù)據(jù)一致性問題。多個客戶端的寫操作有順序問題，而在GFS中可以通過只允許Append操作得到一個比較好的一致性模型。

4. 數(shù)據(jù)存儲不是有序，無法執(zhí)行Mapreduce；Mapreduce是目前允許機器故障，具有強擴展性的最好的并行計算模型，且有開源的Hadoop可以直接使用，Dynamo由于數(shù)據(jù)存儲依賴Hash無法直接執(zhí)行Mapreduce任務。