http://blog.jiguang.cn/couchbase_distributed_storage/

2019-11-08 20:52:53

字體：大中小

來源：轉載

供稿：網友

轉載：http://zhang.hu/couchbase/

Couchbase 中的分布式儲存

.entry-header

概述

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為單位劃分映射到不同服務器節點中進行儲存，劃分規則如下：

均勻的分配有效vbucket和副本vbucket到不同服務器節點中；把有效數據與副本數據劃分到不同物理節點中；在復制多份數據時，盡量有其它節點進行數據傳播；擴展時，以最小化數據遷移量進行復制。

負載均衡

在 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提供了以下幾種模式的復制：

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

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

在對于讀的一致性的權衡，Couchbase 也提供了以下兩種形式：

讀取時，獲取一致性的的數據。此種方式是當數據更新后所有的應用讀到數據都是一樣的。主要原理是讀和寫都是操作有效vbucket。讀取時，可以獲取不一致性的數據。此種方式適合對于對數據一致性不是很重要，對可用性比較注重的場景。主要原理是讀的時候，有效vbucket不可用時，數據會從備份vbucket中獲取數據。

跨數據中心復制（多集群間復制）

跨數據中心復制主要是針對多個集群間的數據復制，此種復制主要以異步的方式通過XDCR協議同步數據到其它集群中備份，從而實現單集群或機房出現問題級的容災?？鐢祿行膹椭剖且詁ucket為單位進行復制的，在管理員操作界面可以通過配置XDCR來進行此種復制方式，下圖為跨數據中心復制示例圖：

容錯

單臺服務器故障的概率是不高的，然而，只要集群的規模足夠大，每天都可能有機器故障發生，系統需要能夠自動處理。首先，分布式存儲系統需要能夠檢測到機器故障，在分布式系統中，故障檢測往往通過租約協議實現。接著，需要能夠將服務復制或者遷移到集群中的其它正常服務的存儲節點。

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

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

分布式協議

DCP (Database Change PRotocol)

DCP 協議是一個高效的二進制協議，它主要用于集群內的數據復制、索引復制、備份數據等等。主要概念有以下幾點：

有序復制，基于每個vbucket存在一個順序序列號，同步時根據序列號進行更新；重啟恢復，當同步連接中斷后，重新連接后，會對沖突數據進行恢復；一致性，使用快照數據同步數據統一性；內存間復制。

XDCR (Cross Data Center Replication)

XDCR提供了多個有效vbucket的數據的復制，主要用于跨數據中心的多集群間的復制。主要概念有一下幾點：

基于bucket復制，兩個集群的同一個bucket可以實現單向或者雙向復制；通過DCP協議保持持續性復制，一個XDCR連接中包括多個DCP數據流。這些流可以根據不同的分區對目的集群進行同步復制；支持多種集群拓撲復制。集群間可以通過單向，雙向復制。多個集群可以實現1對1,1對多,多對1等的集群復制拓撲圖；安全復制。數據中心見傳輸數據可以使用SSL進行加密；最終一致性和解決數據沖突的能力。當出現沖突數據，會使用元數據的序列值，CAS值，文檔標簽和過期時間限制對數據進行沖突解決。

跨機房部署

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

在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機群間雙向向復制來防止節點故障或者	雙向服務可以用于有效/劃分計算能力的跨數據中心，目的集群數據就可以讀取和寫最終一致性的數據在穩定狀態，你會發現兩個集群在操作同一個數據時發生了沖突，許多用戶使用寫在不同的劃分段來讓各自集群來處理避免沖突。（多主模式）