分布式高可用鍵值對數據庫Riak - 背景篇（1）

Riak簡介

典型的現代關系數據庫在某些類型的應用程序中表現平平，難以滿足如今的互聯網應用程序的性能和可擴展性要求。因此，需要采用不同的方法。在過去幾年中，一種新的數據存儲類型變得非常流行，通常稱為 NoSQL，因為它可以直接解決關系數據庫的一些缺陷。Riak 就是這類數據存儲類型中的一種。
Riak 并不是惟一的一種 NoSQL 數據存儲。另外兩種較流行的數據存儲是 MongoDB 和 Cassandra。盡管在許多方面十分相似，但是它們之間也存在明顯的不同。例如，Riak 是一種分布式系統，而 MongoDB 是一種單獨的系統數據庫，也就是說，Riak 沒有主節點的概念，因此在處理故障方面有更好的彈性。盡管 Cassandra 同樣是基于 Amazon 的 Dynamo 描述，但是它在組織數據方面摒棄了向量時鐘和相容散列等特性。Riak 的數據模型更加靈活。在 Riak 中，在第一次訪問 bucket 時會動態創建這些 bucket；Cassandra 的數據模型是在 XML 文件中定義的，因此在修改它們過后需要重啟整個集群。
Riak 是用 Erlang 編寫的。而 MongoDB 和 Cassandra 是用通用語言（分別為 C++和 Java）編寫，因此 Erlang 從一開始就支持分布式、容錯應用程序，所以更加適用于開發 NoSQL 數據存儲等應用程序，這些應用程序與使用 Erlang 編寫的應用程序有一些共同的特征。
Riak支持Map/Reduce 作業，但是Map/Reduce 作業只能使用 Erlang 或 JavaScript 編寫。

分布式存儲？一個頭疼的問題

目前，基于互聯網的業務都處于量級高速變化的狀態（要么增長特別快，要么萎縮特別快）。一個比較頭疼的問題就是如何存儲并保持高速訪問業務數據。很多公司采用了分布式存儲的解決方案，這帶來了一些更令人頭疼的問題：

很難擴容：如果現在業務發展迅速，3臺主機撐不住了，需要加到5臺主機，那要如何處理呢?首先要更改分類方法，把用戶分成5類，然后重新遷移已經存在的數據。你要在網站上貼個條子，“系統維護中”，然后開始偉大的遷移工程，等到終于遷移完成，發現其實3臺也不用了，用戶都走光了-_-。

數據高可用性無法保證：有一天，發現有一臺數據庫服務器的硬盤壞了，這下麻煩就來了，本來網站就不賺錢，沒用什么高檔機器，只有一個定期的增量備份而已。經過一天復雜的恢復工作，你還要對部分用戶說，麻煩你們把做過的事情再做一遍啊。然后用戶對你說go fuck yourself，你發現你再也不用維護或者恢復用戶數據了，因為他們又走光了。

單點問題：負責把用戶分類，然后決定使用哪個數據服務器的那臺主機是網站的命根子啊，它如果宕機，所有的數據都不能訪問了，它如果滿負荷了，增加數據服務器也不會對整體性能有幫助。我好像看到一臺貼滿著驅邪保平安符咒的pc server。

寫入還要重試：倘若你后臺某個用戶對應的存儲介質因為某不可知原因掛掉了，用戶發現無論發送什么請求后臺都沒反應，也不知道自己的請求到底成功沒有。這時考驗用戶忠誠度和心理素質的時候到了，想想如果是像支付寶買一件奢侈品的時候，你敢重試好幾次么。

接下來我們將針對每個問題將Dynamo的解決方案展示給大家。

Dynamo擴容與一致性哈希

我們運用快遞員與運單的場景，假設我們的數據庫存儲每個快遞員的所有運單記錄。現在有A，B，C，D，E這五臺機器，有200個快遞員，有2000條運單記錄。我們很容易想到通過哈希取模來平均分配這200個快遞員與2000個運單對應關系。通過快遞員對5取模，即A(1,6,11,16…), B(2,7,12,17…), C(3,8,13,18…), D(4,9,14,19…), E(5,10,15,20…)，保存對應的快遞員與運單關系（其實就是快遞員為key運單為value）。
如果這時，我們想擴容到六臺，那么變成A(1,7,13,19…), B(2,8,14,20…), C(3,9,15…), D(4,10,16…), E(5,11,17…), F(6,12,18…). 遷移量非常大。如何減少遷移量呢？
Dynamo采用一致性哈希的方法，首先，我們假設有S=20個邏輯分片。然后200個快遞員的哈希值處理之后落到的區域正好如下圖所示：

每個快遞員的鍵值對都會落到這個環上，假設我們這里一致哈希算法是按快遞員號碼進行的。Shard1負責1-10，Shard2負責11-20，以此類推。因為快遞員的能力是差不多的，所以當資源節點的數量足夠多的時候，可以認為每個節點的負載基本是均衡的。這是原始的consistent hashing。
Dynamo并沒有采用這個模型。這個理想的理論模型跟現實之間有一個問題，在這個理論模型上，每個資源節點的能力是一樣的。我的意思是，他們有相同的cpu，內存，硬盤等，也就是有相同的處理能力。可現實世界，我們使用的資源卻各有不同，新買的n核機器和老的奔騰主機一起為了節約成本而合作。如果只是這么簡單的把機器直接分布上去，性能高的機器得不到充分利用，性能低的機器處理不過來。
所以，Dynamo使每個物理機器按照能力包含不同個分片節點。假設還是剛才那5臺機器, 一種分配方案就是：

這樣，即是一臺機器掛了，所做的遷移量也只是那臺機器上的數據。新加入的機器所要遷移的數據也只是他所要保存的數據。但是，這種方案還是有問題，假設A機器掛了，那么他的所有數據全都跑到了B上，而從上圖可以看出，B的性能不是很好。所以，最好還是采用下種方案避免這種現象：

采用這種方法的前提是邏輯分片個數S要大于物理機個數P(如果P>S，不是不可以，就是多余出來機器沒有分片需要它去承載)。這里就是20>5. 假設考慮到高可用一份數據要復制n份，那么我們就要保證S>n*P.

<script type="text/javascript"> $(function () { $('pre.prettyprint code').each(function () { var lines = $(this).text().split('\n').length; var $numbering = $('<ul/>').addClass('pre-numbering').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i <= lines; i++) { $numbering.append($('<li/>').text(i)); }; $numbering.fadeIn(1700); }); }); </script>

總結

以上是生活随笔為你收集整理的Riak - 背景篇（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。