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

Dynamo對于數據版本的處理

數據版本問題不止存在于分布式系統，這里針對分布式數據庫系統簡單討論下。先看一個簡單的例子，用戶x對key1做了一次寫入操作，我們設值是數字3。然后用戶y讀取了key1，這個時候用戶y知道的值是3。然后用戶x對值做了一個+1操作，將新值寫入，現在key1的值是4了。而用戶y也做了一次+1操作，然后寫入，因為用戶y讀到的值是3，y不知道這個值現在已經變化了，結果按照語義本應該是5的值，現在還是4。
解決這個問題常用的方法是設置一個版本值。用戶x第一次寫入key1 值3的時候，產生一個版本設為v1。用戶y讀取的信息中包括版本編號v1。當x做了加1把值4寫入的時候，告訴server自己拿到的是版本v1，要在v1的基礎上把值改成4。server發現自己保存的版本的確是v1所以就同意這個寫入，并且把版本改成v2。這個時候y也要寫入4，并且宣稱自己是在版本v1上做的修改。但是因為server發現自己手里已經是版本v2了，所以server就拒絕y的寫入請求，告訴y，版本錯誤。這個算法在版本沖突的時候經常被使用。
但是對于如我們剛才描述的分布式數據庫系統，就不能這么做。假設我們設置了N=3 W=1。現在x寫入key1 值3，這個請求被節點A處理，生成了v1版本的數據。然后x用戶又在版本v1上進行了一次key1值4的寫操作，這個請求這次是節點C處理的。但是節點C還沒有收到上一個A接收的版本(數據備份是異步進行的)如果按照上面的算法，他應該拒絕這個請求，因為他不了解版本v1的信息。但是實際上是不可以拒絕的，因為如果C拒絕了寫請求，實際上W=1這個配置，這個服務器向客戶做出的承諾將被打破，從而使得系統的行為退化成W=N的形式。那么C接收了這個請求，就可能產生前面提到的不一致性。如何解決這個問題呢?
Dynamo 的方法是保留所有這些版本，用vector clock記錄版本信息。當讀取操作發生的時候返回多個版本，由客戶端的業務層來解決這個沖突合并各個版本。當然客戶端也可以選擇最簡單的策略，就是最近一次的寫覆蓋以前的寫。
舉個例子：
假設處理運單一，一開始請求發送到了E機器，更新status為1。E對應的虛節點上會記錄E1((status:1,E))，并同步給其他備份節點。

之后請求又發送到了E機器，更新status為2。E對應的虛節點上會更新記錄E2((status:2,E))，并同步給其他備份節點。

假設這時 ，有更新請求到了B和A上，B和A會分別更新自己的記錄為B1(((status:2,E),(status:3,B))和A1(((status:2,E),(status:4,A))

之后，經過同步，每個虛節點會保存沖突版本，直到業務端解決沖突

啰嗦下NoSQL與數據庫趨勢

首先還是存在了20多年的關系型數據庫，它還是很成功的，能夠穩定的運行在單機環境并可靠的持久化數據，并能控制并發訪問有效的處理事務。
但是這種基于關系代數創造出來的關系型數據庫，與研發人員設計的實體對象類，并不是很匹配。于是出現了一些類似于Hibernate和MyBatis這樣的ORM（對象關系映射）層框架產品。
傳統上，應用的各個模塊都把同一份數據庫當做共用的集成點。但是現在，流行的應用設計思想比如說微服務的思想可以理解為每個應用模塊都會封裝自己的數據庫，并通過服務彼此集成。集群化的思想也日趨流行，但是，傳統的關系型數據庫在集群上的表現很差。這也是CAP理論的驗證，因為傳統的關系型數據庫，一致性（C）和可用性（A）保證得很好，但是分區集群容錯性（P）表現的就不那么好了。
于是，強調不同CAP維度的NoSQL出現了。

Riak簡介

Riak是Basho公司推廣開發的基于Amazon的Dynamo理論的鍵值對分布式數據庫。Basho Technologies，分布式NoSQL數據庫Riak的創建者，在經歷一輪強勁的增長之后獲得了2500萬美元的G輪融資，這些資金正被用來擴大開發和營銷活動。Riak是開源的，但是Basho的Riak Enterprise增加了multi-data center復制等主要功能，這項特性使得在全球范圍內分布式工作負載、監控和不間斷支持成為可能。
我們可以把Riak理解為之前我們所述Dynamo理論的一個不錯的實現。
Riak到現在主要經歷了兩個時代，分別是1.0和2.0時代。
Riak主要有如下幾個重要特性：

鍵值型數據庫，所有鍵值對放在不同的桶（bucket）中。

基于NWR模型的高可用，Riak可以通過讀寫多個服務器來保證網絡斷掉或者機器宕機時維持服務可用。

集群增加新的節點時，不用很繁瑣的操作，可以實現便捷擴容

Riak可以將數據均勻的分布到集群內的每一個節點上，從而保證性能近似線性地隨著機器增加而增加。

Riak是無主集群，在集群中某一節點宕機或者永久性損壞不會影響整個集群

版本向量解決分布是數據沖突。就是本文開頭說的沖突解決辦法

Map-reduce操作

在2.0以后，引入了如下更多的特性：

新的CRDT（Conflict-free Replicated Data Type）數據類型。但是需要Bucket顯示指定特定的數據類型

強一致性改進，Riak安全相關，新型Riak搜索引擎（集成Solr） - 這些需要Riak配置文件顯式地打開。

Dotted Version Vectors (DVVs) 新型的版本向量方案

<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 - 背景篇（3）的全部內容，希望文章能夠幫你解決所遇到的問題。

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