Couchbase 中的分佈式儲存

概述

Couchbase 是一個具備高性能、可擴展性和可 用性強的數據庫引擎。它可讓開發人員經過 NoSQL 的鍵值存儲（二進制或者JSON）或者使用 N1QL 的形式對數據進行操做（N1QL 是很是相似於 SQL 的一種語法操做 JSON 數據的方式）。以如今總體架構來看，Couchbase 是往分佈式數據庫的方向發展下去。

分佈式數據庫通常是從單機關係數據庫擴展而來，用於存儲結構化數據。分佈式數據庫採用二維表格組織數據，提供SQL關係查詢語言，支持多表關聯，嵌套子查詢等複雜操做，並提供數據庫事務以及併發控制。

Couchbase 的數據服務在單機、 集羣安裝，集羣、多集羣通訊都是很是簡單去作的。在必定的場景下，使用Couchbase是很是好的選擇。

本文主要使用分佈式儲存的一些理論來分析 Couchbase 的數據服務的分佈式數據儲存模型。

數據儲存

存儲引擎直接決定了存儲系統可以提供的性能和功能。在 Couchbase 的數據儲存分對象緩存和數據儲存引擎。以下圖所示應用對數據的操做首先是對內存操做，而後纔會異步更新至數據儲存引擎中。對於 Couchbase，數據層 以 memcached API 對數據進行交互，系統在 memcached 程序中嵌入持久化引擎代碼對數據進行緩存、複製、持久化等操做，持久化操做就是同步數據至 CouchDB 中（新版代碼中增長了forestDB引擎）。對於圖中的複製是在第四節中詳細介紹。

 

對象緩存

對象緩存提供先內存儲存的架構，使得的讀與寫的操做下降了延遲。對象儲存是屬於在內存中以hash儲存方式儲存，支持增、刪、改，以及隨機讀取操做，其哈希分片大小，根據所儲存的數據項的量會動態變更。以下圖，對象緩存根據key值得相關運算計算出分片的哈希值，而後會根據根據所儲存項的多少，在一個哈希分片以鏈表串連數據，每一個內存中儲存的數據結構見圖所示。

 

Couchbase 中讀數據是先從內存中查找key值是否存在，若是存在則返回值，若是不存在緩存中，則會從磁盤中獲取數據，若是數據存在，放入緩存，最後在返回數據值。

注：對於對象緩存大小的設置，在管理員操做平臺中，能夠爲每一個bucket設置對應的RAM內存的大小。

數據儲存引擎

Couchstore（Couchbase的數據儲存引擎）是按vbucket爲單位的文件儲存在文件系統中。Couchstore應用B+樹算法經過key值去快速指向它的內容。 爲了高效的寫, Couchstore應用了追加寫的模型（見下文介紹）對每個文件進行高效和安全的寫操做。

注：在Couchbase中，bucket是用戶所操做文檔數據的集合，vbucket是系統平均劃分bucket的數據進行分片數據的集合。

B+樹結構

 以下圖所示：主節點指向中間節點. 這些中間節點指向葉節點。主節點和中間節點針對它們的子樹能夠劃分指向文檔範圍的大小。葉節點儲存了文檔ID和元數據指向值所儲存的文件位置。

 

追加寫模型

追加寫模式即全部的寫操做只追加數據到文件尾部，而不修改老的數據，系統中的數據刪除或者更新後，原來的數據成爲垃圾數據，這能夠加快磁盤的寫速度。若是 這些數據一直保存下去，文件會無限膨脹下去，爲了解決這個問題，須要按期執行合併操做以實現垃圾回收。所謂合併操做，即將全部老數據文件中的數據掃描一遍 並生成新的數據文件，這裏的合併其實就是對同一個key的多個操做以只保留最新一個的原則進行刪除，每次合併後，新生成的數據文件就再也不有冗餘數據了。

數據分佈

分佈式系統區別於傳統單機系統在於可以將數據分佈到多個節點，並在多個節點之間實現負載均衡。

Couchbase 數據分佈

在Couchbase數據分佈是按計算分配到多個節點上，每一個節點都儲存兩部分數據有效數據和副本數據，客戶端對數據的操做主要是按照節點中對應的有效數據進行操做，執行壓力會部分到不一樣的節點，相似以下圖所示：

 

Couchbase的集羣管理是由erlang/otp進行集羣通訊管理，集羣之間使用心跳機制進行監測服務器節點健康監測，配置參數信息是同步到每個節點上進行儲存。整個集羣以vbucket爲單位劃分映射到不一樣服務器節點中進行儲存，劃分規則以下：

 

1. 均勻的分配有效vbucket和副本vbucket到不一樣服務器節點中；
2. 把有效數據與副本數據劃分到不一樣物理節點中；
3. 在複製多份數據時，儘可能有其它節點進行數據傳播；
4. 擴展時，以最小化數據遷移量進行復制。

負載均衡

在 Couchbase 中，咱們所操做的每個bucket會邏輯劃分爲1024個vbucket，其數據的儲存基於每一個vbucket儲存而且每一個 vbucket都會映射到相對應的服務器節點，這種儲存結構的方式叫作集羣映射。以下圖所示，當應用與Couchbase服務器交互時，會經過SDK的與 服務器數據進行交互，當應用操做某一個的bucket的key值時，在SDK中會經過哈希的方式計算，使用公式crc32(key)%1024肯定key 值是屬於1024個vbucket中的某個，而後根據vbucket所映射的節點服務器對數據進行操做。

 

複製

爲了保證分佈式存儲系統的高可靠和高可用，數據在系統中通常存儲多個副本。當某個副本所在的存儲節點出現故障時，分佈式存儲系統可以自動將服務切換到其它的副本，從而實現自動容錯。

複製的概述

分佈式存儲系統中數據保存多個副本，通常來講，其中一個副本爲主副本，其它副本爲備副本，常見的作法是數據寫入到主副本，由主副本肯定操做的順序並複製到其它副本。如下是兩種複製類型：

• 強同步複製：複製協議要求主備同步成功才能夠返回客戶端寫成功，這種協議稱爲強同步協議。強同步協議提供了強一致性，可是，若是備副本出現問題將阻塞寫操做，系統可用性較差。
• 異步複製：在異步複製下，主副本不須要等待備副本的迴應，只須要本地修改爲功就能夠告知客戶端寫操做成功。異步複製的好處在於系統可用性較好，可是一致性較差，若是主副本發生不可恢復故障，可能丟失最後一部分更新操做。

Couchbase 中的複製

集羣內複製（單集羣內複製）

集羣內複製主要針對同一個集羣中多個節點的數據進行多份複製備份，而且複製的份數會分佈到不一樣的節點中。在數據分佈中咱們知道每一個節點都會儲存有效的 vbucket和複製的vbucket。以下圖展現，當應用對對數據進行寫操做，此操做會先到集羣節點中所對應有效的vbucket的數據進行寫操做，並 且有效的vbucket節點會根據DCP協議傳輸寫操做的變動傳輸到複製的vbucket所對應的節點，對複製的vbucket進行變動。可複製的 vbucket的份數，能夠在操做bucket的時候進行配置，備份數量爲1-3份。

 

集羣內複製在Couchbase中能夠由應用在寫數據的時候選擇一致性與可用性之間的權衡，Couchbase提供瞭如下幾種模式的複製：

1. 內存級的儲存。此種模式是當應用寫數據時，當數據已經儲存到內存中後，就會返回正確回覆給應用，同步其它節點和持久化儲存都是由異步處理。此種模式速度最快，相對的容錯性也是最差。
2. 內存+持久化級的儲存。此種模式是當應用寫數據時，只有數據儲存在內存和硬盤中後，纔會返回正確回覆給應用，同步其它節點是異步處理方式。此種模式，若是單節點出現問題，數據可能出現不一致性。
3. 內存+備份節點級的儲存。此種模式是當應用寫數據時，只有數據儲存同步到其它節點的內存中時，纔會返回正確回覆給應用，持久話處理都是異步處理，應用是能夠選擇出同步數據的節點數量。此種模式保證了數據必定備份和容災，可是也有必定可能數據沒有持久話會丟失。
4. 內存+持久化+備份節點的儲存。此種模式是當應用寫數據時，數據存儲必須知足所須要的節點中內存複製和持久化都完成後，才能夠返回正確給應用。這種模式保證即便有效vbucket節點機器出現沒法恢復的故障。

注：在程序流程中，第2,3,4種儲存方式持久化數量節點和備份節點的數量是由客戶端進行設置和進行檢測的。第1種儲存方式客戶端是直接進行操做而且沒有檢測過程的。

在對於讀的一致性的權衡，Couchbase 也提供瞭如下兩種形式：

1.  讀取時，獲取一致性的的數據。此種方式是當數據更新後全部的應用讀到數據都是同樣的。主要原理是讀和寫都是操做有效vbucket。
2. 讀取時，能夠獲取不一致性的數據。此種方式適合對於對數據一致性不是很重要，對可用性比較注重的場景。主要原理是讀的時候，有效vbucket不可用時，數據會從備份vbucket中獲取數據。

跨數據中心複製（多集羣間複製）

跨數據中心複製主要是針對多個集羣間的數據複製，此種複製主要以異步的方式經過XDCR協議同步數據到其它集羣中備份，從而實現單集羣或機房出現問題級的容災。跨數據中心複製是以bucket爲單位進行復制的，在管理員操做界面能夠經過配置XDCR來進行此種複製方式，下圖爲跨數據中心複製示例圖：

 

容錯

單臺服務器故障的機率是不高的，然而，只要集羣的規模足夠大，天天均可能有機器故障發生，系統須要可以自動處理。首先，分佈式存儲系統須要可以檢測到機器故障，在分佈式系統中，故障檢測每每經過租約協議實現。接着，須要可以將服務複製或者遷移到集羣中的其它正常服務的存儲節點。

在Couchbase中可分單集羣中和多集羣容錯：

1. 單集羣中能夠設置auto-failover的方式來實現自動容錯。管理員可在後臺設置auto-failover的時間，當集羣檢測到單點機器超過設置的時間後，則選取uuid/seqno爲最新的機器的副本數據激活，更新vbucket所映射的服務器來恢復業務。
2. Couchbase現階段沒有實現多集羣容錯的方式，在設計應用的時候，須要檢測單機羣問題，進行集羣的切換來恢復業務。

分佈式協議

DCP (Database Change Protocol)

DCP 協議是一個高效的二進制協議，它主要用於集羣內的數據複製、索引複製、備份數據等等。主要概念有如下幾點：

1. 有序複製，基於每一個vbucket存在一個順序序列號，同步時根據序列號進行更新；
2. 重啓恢復，當同步鏈接中斷後，從新鏈接後，會對衝突數據進行恢復；
3. 一致性，使用快照數據同步數據統一性；
4. 內存間複製。

XDCR (Cross Data Center Replication)

XDCR提供了多個有效vbucket的數據的複製，主要用於跨數據中心的多集羣間的複製。主要概念有一下幾點：

1. 基於bucket複製，兩個集羣的同一個bucket能夠實現單向或者雙向複製；
2. 經過DCP協議保持持續性複製，一個XDCR鏈接中包括多個DCP數據流。這些流能夠根據不一樣的分區對目的集羣進行同步複製；
3. 支持多種集羣拓撲復制。集羣間能夠經過單向，雙向複製。多個集羣能夠實現1對1,1對多,多對1等的集羣複製拓撲圖；
4. 安全複製。數據中心見傳輸數據可使用SSL進行加密；
5. 最終一致性和解決數據衝突的能力。當出現衝突數據，會使用元數據的序列值，CAS值，文檔標籤和過時時間限制對數據進行衝突解決。

跨機房部署

在分佈式系統中，跨機房問題一直都是比較複雜問題。機房之間的網絡延時較大，且不穩定。跨機房問題主要包含兩個方面：數據同步以及服務切換。

在Couchbase中能夠以一下兩種方式跨機房：

• 集羣總體切換，這種方式是兩個機房部署了相同的Couchbase集羣，由XDCP以異步方式同步集羣副本，當出現問題時，可切換集羣。這種方式的問題是 當主機房總體出現故障時，有兩種選擇：要麼將服務切換到備機房，忍受數據丟失的風險；要麼中止服務，直到主機房恢復爲止。所以，主備機房切換每每是手工 的，容許用戶根據業務的特色選擇「丟失數據」或者「中止服務」。
• 單個集羣跨機房，這種方式是將單個集羣部署到多個機房，容許不一樣數據分片的主副本位於不一樣的機房。這種方式主要是考慮到寫數據的時候，一致性比較強的數據是同步到每一個節點中才算寫成功的案例，當機房出現問題時，大部分數據是能夠繼續可用。

Couchbase的分佈式及理論

CAP理論：一致性（Consistency），可用性（Availability）以及分區可容忍性（Tolerance of network Partition）三者不能同時知足。

• 一致性：讀操做老是能讀取到以前完成的寫操做結果，知足這個條件的系統稱爲強一致系統，這裏的「以前」通常對同一個客戶端而言；
• 可用性：讀寫操做在單臺機器發生故障的狀況下仍然可以正常執行，而不須要等待發生故障的機器重啓或者其上的服務遷移到其它機器；
• 分區可容忍性：機器故障、網絡故障、機房停電等異常狀況下仍然可以知足一致性和可用性。

分佈式存儲系統要求可以自動容錯，也就是說，分區可容忍性老是須要知足的，所以，一致性和寫操做的可用性不能同時知足。

如下表格描述了Couchbase 所對應的 CAP 理論的部署方式：

部署拓撲結構	故障範圍保護	CAP 平衡	評論
單Couchbase服務器機羣	節點故障(例如, 節點以前硬件故障,通訊失敗)	能夠配置成CP，而且能夠經過配置auto failover操做獲得有效性	當故障時，Couchbase服務器容許有效的讀和配置 auto-failover一個不多的時間超時來恢復寫的可用性。
多Couchbase服務器機羣單向XDCR複製	節點或機羣故障 (例如: 數據中心天然災害)	AP是經過XDCR機羣間單向複製來防止節點故障或者	單向複製能夠用於同步數據在秒級計算能力數據中心中，   目的集羣數據就能夠經過最終一致性的數據用來讀取和當原集羣故障時，升級爲讀寫集羣（主從模式業務，讀寫分離）
多Couchbase服務器機羣雙向XDCR複製	節點或機羣故障(例如: 數據中心天然災害)	AP是經過XDCR機羣間雙向向複製來防止節點故障或者	雙向服務能夠用於有效/劃分計算能力的跨數據中心，目的集羣數據就能夠讀取和寫最終一致性的數據在穩定狀態，你會發現兩個集羣在操做同一個數據時發生了衝突，許多用戶使用寫在不一樣的劃分段來讓各自集羣來處理避免衝突。（多主模式）

 最終一致性主要是來源於 BASE 理論。BASE 理論是對 CAP 理論的延伸，核心思想是即便沒法作到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用能夠採用適合的方式達到最終一致性（Eventual Consitency）。

基本可用（Basically Available）
基本可用是指分佈式系統在出現故障的時候，容許損失部分可用性，即保證核心可用。
電商大促時，爲了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。
軟狀態（ Soft State）
軟狀態是指容許系統存在中間狀態，而該中間狀態不會影響系統總體可用性。分佈式存儲中通常一份數據至少會有三個副本，容許不一樣節點間副本同步的延時就是軟狀態的體現。
最終一致性（ Eventual Consistency）
最終一致性是指系統中的全部數據副本通過必定時間後，最終可以達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊狀況。

總結

以上大體介紹 Couchbase 服務器的數據的分佈式儲存架構及一些分佈式理論的知識。

Couchbase在系統分佈式方面提供了基礎的支持，然而在分佈 式儲存的一致性、可用性和分區性是須要有所權衡，Couchbase 服務器提供了多種選擇的方式讓用戶根據本身的業務場景選擇不一樣的非功能性的需求點，來 實現對數據的儲存。