dynamo中文

1、DynamoDynamo 簡介四 20TH由道安 道安發(fā)表在 Dynamo8個評論 個評論這個小文打算寫成入門級的介紹，所以很多語言不追求準(zhǔn)確性。本介紹參考 Amazon 的 Dynamo 論文。需要更詳細(xì)更準(zhǔn)確信息的同學(xué)請直接閱讀原文。(原文地址http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf) 這篇論文本身沒提出什么新的思想

2、，正如論文中所說，貢獻在于把非常多的技術(shù)結(jié)合到了一起，來完成一個系統(tǒng)。Dynamo 是個什么東東呢？他是 Amazon 公司的一個分布式 key/value 存儲引擎。那么這個什么引擎又是什么？首先，假設(shè)一個場景，你的網(wǎng)站要存儲用戶登陸的 ip。這個問題怎么解決呢？傳統(tǒng)的方法是用數(shù)據(jù)庫。數(shù)據(jù)庫提供了方便的操作接口，復(fù)雜的查詢能力以及事物的保證。多好的解決方案啊。盡管應(yīng)用不需要什么復(fù)雜查詢，也不需要事物。好，現(xiàn)在假設(shè)大家都很喜歡你的網(wǎng)站，

3、訪問的人越來越多。一個數(shù)據(jù)庫已經(jīng)處理不過來了。于是你安裝了3臺數(shù)據(jù)庫主機，把用戶分成了三類（男人，女人，it 人；總是有某種方法把用戶分成數(shù)目大致差不多的幾個部分吧） 。每次訪問的時候，先看用戶屬于哪一類，然后直接訪問存儲那類用戶數(shù)據(jù)的數(shù)據(jù)庫。于是處理能力增加了三倍。這個時候你已經(jīng)實現(xiàn)了一個分布式的存儲引擎，Dynamo 就是一個類似的東西。只是它的可靠性，可用性等方面更好一點而已。下面我們看看那個簡單的分布式存儲系統(tǒng)有什么不方便的地方

4、，而Dynamo 是如何解決的。先列舉一下簡單的分布式系統(tǒng)可能存在的問題吧：1 很難擴容：如果現(xiàn)在業(yè)務(wù)發(fā)展迅速，3臺主機撐不住了，需要加到5臺主機，那要如何處理呢？首先要更改分類方法，把用戶分成5類，然后重新遷移已經(jīng)存在的數(shù)據(jù)。你要在網(wǎng)站上貼個條子，“系統(tǒng)維護中”，然后開始偉大的遷移工程，等到終于遷移完成，發(fā)現(xiàn)其實3臺也不用了，用戶都走光了。2 數(shù)據(jù)可靠性無法保證：有一天，發(fā)現(xiàn)有一臺數(shù)據(jù)庫服務(wù)器的硬盤壞了。麻煩了，本來網(wǎng)站就不賺錢，沒用

5、什么高檔機器，只有一個定期的增量備份而已。經(jīng)過一天復(fù)雜的恢復(fù)工作，你還要對部分用戶說，麻煩你們把做過的事情再做一遍啊3 單點問題：負(fù)責(zé)把用戶分類，然后決定使用哪個數(shù)據(jù)服務(wù)器的那臺主機是網(wǎng)站的命根子啊，它如果宕機，所有的數(shù)據(jù)都不能訪問了，它如果滿負(fù)荷了，增加數(shù)據(jù)服務(wù)器也不會對整體性能有幫助。我好像看到一臺貼滿著驅(qū)邪保平安符咒的 pc server。這幾個問題，看似不大，解決起來還真的不容易呢。尤其是想到自己的網(wǎng)站也許有一天也會和 goog

6、le 有一樣多的用戶（可能因為你是天才或者 google 快倒閉了） ?，F(xiàn)在我們衡。這要怎么辦呢？我們可以把那個數(shù)據(jù)圓分成 Q 等份（每一個等份就是一個虛節(jié)點） ，這個 Q 要遠大于我們的資源數(shù)?，F(xiàn)在假設(shè)我們有 S 個資源，那么每個資源就承擔(dān) Q/S 個等份。 當(dāng)一個資源節(jié)點離開系統(tǒng)的時候，它所負(fù)責(zé)的等份要重新均分到其他資源節(jié)點上， 一個新節(jié)點加入的時候，要從其他的節(jié)點”偷”到一定數(shù)額的等份。 這個策略下，當(dāng)一個節(jié)點離開系統(tǒng)的時候，雖

7、然需要影響到很多節(jié)點，但是注意，遷移的數(shù)據(jù)總量只是離開那個節(jié)點的數(shù)據(jù)量。同樣，一個新節(jié)點的加入，遷移的數(shù)據(jù)總量也只是一個新節(jié)點的數(shù)據(jù)量。之所以有這個效果是因為 Q 的存在，使得增加和減少機器的時候不需要對已有的數(shù)據(jù)做重新哈希。這個策略的要求是 Q>>S(其實還有存儲備份的問題，現(xiàn)在還沒介紹到，假設(shè)每個數(shù)據(jù)存儲 N 個備份 則要滿足 Q>>S*N)。如果業(yè)務(wù)快速發(fā)展，使得不斷的增加主機，從而導(dǎo)致 Q 不再滿足 Q&

8、gt;>S，那么這個策略將不斷的退化。(Dynamo 論文在 section 6。2 比較了三種策略的狀況 ，本文只是簡單介紹其思想，不是詳細(xì)翻譯)2 數(shù)據(jù)的可靠性:因為我們使用的是廉價的 pc 機，硬盤損毀或者是其他原因?qū)е碌闹鳈C不可用是很經(jīng)常的事情。做這樣一個估算，假設(shè)一臺 pc 機平均三年就會有一次失效，不可用。那么當(dāng)一個一千臺機器的集群，基本上每天都有機器壞掉，所以某主機不可用是常態(tài)，系統(tǒng)必須可以在這樣的情況下繼續(xù)提供服

9、務(wù)(哦 雖然你的網(wǎng)站現(xiàn)在剛剛只需要4臺主機，可是別忘了，它要成長成為 google 的)。當(dāng)然，廉價 pc 的好處就是便宜。所以我們可以增加系統(tǒng)中數(shù)據(jù)的備份來使得系統(tǒng)在某臺機器掛掉的時候仍舊可用。大家最先想到的方案可能就是對每個節(jié)點，建立一個備份節(jié)點，如果主節(jié)點壞掉了，備份節(jié)點可以立刻頂上去(雙機熱備)。但是仔細(xì)想一下，這個方案是讓人不放心的。因為當(dāng)一主一備中的某一臺機器壞掉，另外一臺就成了一個單點運行的節(jié)點。這個時候另外一個節(jié)點一旦

10、發(fā)生錯誤，服務(wù)就變得不可用，數(shù)據(jù)也有可能丟失。在一個要求高可靠性的系統(tǒng)上，這是不可忍受的。我們剛剛估算了一個大的集群每天都有機器掛掉。而這種錯誤，一定要人工介入才能解決。想想系統(tǒng)管理員每天在機房里更換主機的情景以及其他不可預(yù)料情況(系統(tǒng)管理員休假或者新買的主機沒按時到貨等)，再想想系統(tǒng)每天都有節(jié)點在單點運行，真的是很可怕的事情。事實上,一般工業(yè)界認(rèn)為比較安全的備份數(shù)應(yīng)該是3份。好，那么我們看看做這個備份的時候需要注意的問題。首先，如何選

11、擇備份節(jié)點。我們可以簡單的選擇順序上的后兩個節(jié)點為備份節(jié)點，比如存在節(jié)點 A 的數(shù)據(jù)，備份到節(jié)點 B 和 C。但是當(dāng)我們前面引入了虛節(jié)點的概念的時候就要注意了，有可能 C 節(jié)點和 A 節(jié)點在同一臺物理機器上，這個時候就不能選擇 C 做為 A 的備份了。下一個問題，當(dāng)一個節(jié)點離開系統(tǒng)的時候，比如宕機，這個節(jié)點上存儲的信息需要繼續(xù)備份到其它節(jié)點上。雖然節(jié)點離開了系統(tǒng)，但是因為備份的存在,我們通過其他節(jié)點可以恢復(fù)出本節(jié)點的所有信息，因為該節(jié)點

12、的離開，這部分信息的備份數(shù)會比要求的備份數(shù)少一，所以需要把這部分?jǐn)?shù)據(jù)做再備份。同樣，當(dāng)一個節(jié)點加入系統(tǒng)，從其他節(jié)點偷了數(shù)據(jù)后，其他節(jié)點也需要相應(yīng)減少備份數(shù)。而一個節(jié)點如果只是暫時性的不可達，也就是失效一個很短的時間（這種情況是最常發(fā)生的） ，那么需要其他節(jié)點暫時接管這個節(jié)點的工作，在其可用的時候，把數(shù)據(jù)增量傳送回該節(jié)點。在設(shè)計上述需求的解決方案的時候，還要考慮一個問題，各個節(jié)點間數(shù)據(jù)備份是同步還是異步。假設(shè)我們要求寫請求總是盡可能的成功

13、，那么我們的策略是寫任何一個節(jié)點成功就認(rèn)為成功。節(jié)點之間的數(shù)據(jù)通過異步形式達成一致。這個時候讀請求可能讀不到最新寫進去的信息，比如我們一個數(shù)據(jù)在 A B C 三個節(jié)點各存一份（系統(tǒng)中有三個備份的時候，下面的討論都是基于這個假設(shè)的） ，那么當(dāng)寫 A 成功后，另外一個進程從節(jié)點 C 讀數(shù)據(jù)，這個時候 C 還沒收到最新的數(shù)據(jù)，只能給讀請求一個較老的版本。這個可能會帶來大問題；同樣，如果我們希望讀請求總能讀到正確的數(shù)據(jù)，那我們的策略是寫的時候要