《案例｜S3、Cassandra、HDFS設計中隱藏的高可用法》要點：
本文介紹了案例｜S3、Cassandra、HDFS設計中隱藏的高可用法，希望對您有用。如果有疑問，可以聯(lián)系我們。

Anything that can go wrong will go wrong.

會出錯的事總會出錯.————墨菲定律

高可用 NoSQL 數(shù)據(jù)庫是指服務無中斷地持續(xù)運行的系統(tǒng).許多基于網(wǎng)站的業(yè)務要求數(shù)據(jù)服務能夠一直不中斷.例如,在線購物的數(shù)據(jù)庫需要保證 7 x 24 的可用性.

為什么需要它們一直運行?假設你的數(shù)據(jù)庫支撐著一個全球化的電子商務網(wǎng)站,那么數(shù)分鐘的宕機就可能造成一個消費者的購物車被清空,或是系統(tǒng)在德國主要消費時段停止響應.這些類型的故障將會使你的顧客轉(zhuǎn)而選擇你的競爭對手并降低你的消費者信任度.

分布式 NoSQL 系統(tǒng)降低了那些需要可擴展性和永久在線特性的系統(tǒng)的每筆交易成本.雖然多數(shù) NoSQL 系統(tǒng)使用非標準的查詢語言,但它們的設計和可以部署在低成本的云平臺的能力,為那些因初創(chuàng)且需要提供永久在線功能的公司提供了可能的選擇.

度量 NoSQL 數(shù)據(jù)庫的可用性

描述系統(tǒng)整體可用性最常用的方法是用“9”來描述可用性,其中的“9”是指在設計上的可用性概率中出現(xiàn)“9”的次數(shù).所以“3 個 9”意味著一個系統(tǒng)被預測可以在 99.9% 的情況下可用,而“5 個 9”意味著那個系統(tǒng)應該有 99.999% 的可能是可用的.

下表展示了一個基于典型可用性目標計算出的每年宕機時間的例子.

可用性目標樣例和年宕機時間

量化整體系統(tǒng)可用性并不僅僅是計算出某個數(shù)字.為了客觀地評估 NoSQL 系統(tǒng),還需要了解系統(tǒng)可用性中的細化指標.

如果一個業(yè)務部門聲明他們不能承擔一個日歷年宕機 8 小時的后果,那么就需要構(gòu)建一個提供 3 個 9 可用性的基礎設施系統(tǒng).多數(shù)固定電話交換機的設計目標是達到 5 個 9 的可用性,或每年不超過 5 分鐘的宕機時間.現(xiàn)今,除了某些需要更高可用性的場景,5 個 9 被認為是數(shù)據(jù)服務的黃金標準.

業(yè)界使用服務級別協(xié)議(service level agreement,SLA)這個術(shù)語來描述任何數(shù)據(jù)服務期望達到的可用性指標.SLA 是服務提供商和客戶之間達成的一種書面協(xié)議.它定義了服務商需要提供的服務及其期望的可用性和響應時間,而非服務的提供方式.在起草 SLA 時需要考慮以下因素.

• 按每年在線時長比例計算,服務整體上期望達到的可用性是多少?
• 在普通操作的情況下,服務一般的平均響應時間是多少?服務請求與響應之間的時間通常以毫秒為單位.
• 服務在設計上能處理的最大請求數(shù)是多少?這項指標通常按每秒的請求數(shù)計算.
• 服務的請求數(shù)是否存在周期性變化?例如,在諸如每天某個特定時間、每周或每月中的幾天、每年里的節(jié)假購物日或體育活動日等特定時間段內(nèi),是否存在可預期的請求高峰?
• 如何監(jiān)控系統(tǒng)和匯報服務可用性?
• 服務請求響應時間的分布曲線的趨勢是什么?追蹤平均響應時間可能用處不大,大家通常關(guān)心的是響應中最慢的 5% 請求.
• 遭遇服務中斷的情況下,應該遵循怎樣的恢復流程?

NoSQL 系統(tǒng)的可用性配置也許會和上面這些普適規(guī)則有出入,但關(guān)注點都不應該只是某個單一可用性指標.

案例研究：亞馬遜 S3 的 SLA

現(xiàn)在,讓我們來看看亞馬遜為 S3 存儲服務編寫的 SLA.亞馬遜的 S3 是現(xiàn)今最可靠的基于云端的 KV 存儲服務,且即使在遇到大量讀寫高峰的情況下也能持續(xù)良好運行.傳聞中,這個系統(tǒng)中存儲的數(shù)據(jù)在 2012 年夏季達到了 1 萬億條,為目前容量最大的云端存儲.這些數(shù)據(jù)平均下來大概能達到全球人均 150 條記錄.

亞馬遜在網(wǎng)站上聲明了如下數(shù)個可用性指標.

• 年度數(shù)據(jù)可靠性設計值——這項指標是指在一年中丟失一條 KV 數(shù)據(jù)的可能性.亞馬遜聲稱他們的可靠性設計值是 99.999999999%,即 11 個 9.這項數(shù)據(jù)根據(jù)存儲在 3 塊硬盤上的數(shù)據(jù)在進行備份前遇到所有硬盤均發(fā)生故障的可能性計算得出.這意味著如果在 S3 上存儲有 10,000 條數(shù)據(jù)并以每年 1 千萬條的速率增加,那么會有 50% 的可能丟失 1 條數(shù)據(jù).這應該不會讓你經(jīng)常擔心得夜不能寐.但是需要注意的是,設計值并不能等同于服務保證.
• 年度可用性設計值——這項指標是指在最壞的情況下,每年無法寫入新數(shù)據(jù)或讀取舊數(shù)據(jù)的總時長.亞馬遜聲稱在最壞的情況下,S3 仍有 99.99% 即 4 個 9 的可用性.換句話說,亞馬遜認為 KV 數(shù)據(jù)存儲每年可能有 53 分鐘的不可用時間.但實際上,用戶享受到的是遠高于該設計值的服務保障.
• 月 SLA 承諾——S3 的 SLA 聲明：如果系統(tǒng)在任意的一個月內(nèi)不能達到 99.9% 的在線,亞馬遜將會返給用戶 10% 的服務費用；如果數(shù)據(jù)在一個月中有 1% 的情況無法訪問,用戶將得到 25% 的服務費用返還.但實際上,我們從沒聽說哪個亞馬遜用戶得到過 SLA 服務返點.

仔細閱讀亞馬遜的 SLA 對你仍會有幫助.例如,協(xié)議定義錯誤率為 S3 返回了內(nèi)部錯誤代碼的請求個數(shù),但完全沒有提到任何與緩慢的響應時間相關(guān)的條目.

在實踐中,多數(shù)用戶將獲得的可用性遠超過 SLA 中寫明的最小值.一個獨立的測試服務發(fā)現(xiàn) S3 能夠達到 100% 的可用性,即使在長時間高負載的情況下也一樣.

預測系統(tǒng)可用性

如果要構(gòu)建一個 NoSQL 數(shù)據(jù)庫,就要能夠預測這個數(shù)據(jù)庫的可靠性.你也需要一些工具幫助你分析數(shù)據(jù)庫服務的響應時間.

可用性的預測方法是通過觀測每個被依賴的(單點故障)系統(tǒng)組件的可用性估計值來計算系統(tǒng)總體可用性.如果每個子系統(tǒng)使用一個像 99.9 這樣的簡單可用性估計值,那么將每個數(shù)值相乘就可以得出系統(tǒng)總體可用性的估計值.

例如,如果有 3 個會造成單點故障的情況——網(wǎng)絡有 99.9% 可用性、主節(jié)點有 99% 可用性、電源有 99.9% 可用性,那么總的系統(tǒng)可用性就是這 3 個數(shù)值的乘積：98.8%(99.9×99×99.9).

如果有像主節(jié)點或名字節(jié)點這樣的單點故障節(jié)點,那么 NoSQL 系統(tǒng)可以平滑地切換到備用節(jié)點而不會造成主要服務中斷.如果一個系統(tǒng)可以快速地從一個失效組件的情況下恢復過來,這就是說該系統(tǒng)有自動故障轉(zhuǎn)移(automatic failover)的特性.

自動故障轉(zhuǎn)移是指系統(tǒng)能夠監(jiān)測到服務失效并自動切換到備用組件的特性.故障恢復是指恢復系統(tǒng)中失效組件到正常狀態(tài)的操作過程.一般情況下,這個過程需要執(zhí)行數(shù)據(jù)同步操作.如果系統(tǒng)只配置了一個備用節(jié)點,必須綜合故障轉(zhuǎn)移失敗的概率和故障恢復前系統(tǒng)再次故障的可能性這兩項數(shù)據(jù)來計算可用性.

除了故障指標,還有一些其他指標可用來評估可用性.如果系統(tǒng)有客戶端請求響應大于 30s 即超時的配置,那么可以計算客戶端請求失敗的總占比.在這種情況下,被稱為客戶端收益(client yield)的量化指標可能是一個更好的參考因素.其中客戶端收益是指任意請求在指定時間間隔內(nèi)返回響應的可能性.

其他指標,比如收獲指數(shù)(harvest metric),可以在引入部分 API 結(jié)果時納入?yún)⒖挤秶?類似聯(lián)合搜索引擎這樣的服務就可能返回部分結(jié)果.例如,搜索 10 個遠程系統(tǒng),如果有一個系統(tǒng)在等待結(jié)果的 30s 時間窗口內(nèi)發(fā)生了故障,那么這次請求的收獲指數(shù)就是 90%.收獲指數(shù)可以通過可用數(shù)據(jù)除以總的數(shù)據(jù)源數(shù)得到.

要找到最適合應用需求的 NoSQL 服務也許需要比較兩個不同系統(tǒng)的架構(gòu),而系統(tǒng)的真正架構(gòu)可能隱藏在網(wǎng)絡服務接口之后.在這種情況下,構(gòu)建一個原型項目并模擬真實負載測試服務也許更有意義.

部署好一個包含壓力測試的原型項目后,需要測量的一個關(guān)鍵指標是讀寫響應時間的頻率分布圖.這些分布圖可為決定是否擴展數(shù)據(jù)庫提供參考.這個分析中的一個關(guān)鍵點是應該關(guān)注響應中最緩慢的 5% 部分花了多長時間完成響應,而不是平均響應時間.一般來說,擁有穩(wěn)定響應時間的服務的可用性比有時出現(xiàn)較高比例緩慢響應的系統(tǒng)要高.讓我們來看看這種情況的一個示例.

評估可用性的實踐

假如小孫要為一個關(guān)心網(wǎng)頁響應時間的業(yè)務部門評估兩個候選 NoSQL 系統(tǒng).網(wǎng)頁由某個 KV 存儲中的數(shù)據(jù)渲染.小孫已經(jīng)將候選項縮小到了兩個 KV 存儲,我們將其叫作服務 A 和服務 B.如下圖所示,小孫通過 JMeter(一種常用的性能監(jiān)控工具)生成了兩者響應時間的分布圖.

平均情況和 95% 的情況下響應時間頻率分布的對比圖.需要注意的是,兩條分布曲線分別對應的是兩個 NoSQL KV 數(shù)據(jù)存儲在負載下的表現(xiàn).服務 A 擁有較低的平均響應時間,但在 95% 的情況下比 B 更慢.服務 B 則是擁有較高的平均響應時間,但 95% 的情況下比 A 更快

當小孫觀測數(shù)據(jù)時,她發(fā)現(xiàn)服務 A 擁有較低的平均響應時間.但在 95% 的情況下,服務 A 響應時間比服務 B 高.服務 B 的平均響應時間可能較高,但仍在網(wǎng)頁響應時間的期望范圍內(nèi).在和該業(yè)務部門就測試結(jié)果討論完后,該團隊選擇了服務 B,因為他們感覺在實際負載情況下服務 B 會有更穩(wěn)定的響應時間.

現(xiàn)在,我們已經(jīng)討論過了預測和量化系統(tǒng)可用性的方法.接下來將探討 NoSQL 集群用來提升系統(tǒng)可用性的策略.

NoSQL 系統(tǒng)的高可用性策略

你最初想要問的幾個問題之一可能是：“如果 NoSQL 數(shù)據(jù)庫崩潰了怎么辦?”

為了解決這個問題,可以創(chuàng)建一個數(shù)據(jù)庫復制.

使用負載均衡器將流量轉(zhuǎn)向到最空閑的節(jié)點

對高可用性有需求的網(wǎng)站會使用一個叫負載均衡器(load balancer)的前端服務.下圖展示了一個負載均衡器的示意圖.

圖中,服務請求從左邊進入系統(tǒng),然后被發(fā)送到一個被稱為負載均衡池(load balancer pool)的資源池中.接著,被發(fā)送給負載均衡器主節(jié)點的服務請求會再被轉(zhuǎn)發(fā)給某個應用服務器.理想情況下,每個應用服務器有某種負載狀況指示來告訴負載均衡器它們的繁忙狀況.最空閑的應用服務器將會接收到負載均衡器轉(zhuǎn)發(fā)的請求.應用服務器響應請求服務并返回結(jié)果.應用服務器也可能向一個或多個 NoSQL 服務器發(fā)送數(shù)據(jù)請求.當查詢請求的結(jié)果返回后,服務也就最終完結(jié).

負載均衡器適用于有大量可以獨立完成服務請求的節(jié)點的場景.為了獲得性能提升優(yōu)勢,所有的服務請求首先到達負載均衡器,再由其分發(fā)給最空閑的節(jié)點.每個應用服務器發(fā)送的心跳信號構(gòu)成了一個正在工作的應用服務器列表.一個應用服務器也可能向一個或多個 NoSQL 數(shù)據(jù)庫發(fā)送數(shù)據(jù)請求.

結(jié)合高可用分布式文件系統(tǒng)和 NoSQL 數(shù)據(jù)庫

多數(shù) NoSQL 系統(tǒng)的設計目標之一就是能夠和像 Hadoop 分布式文件系統(tǒng)(HDFS)這樣的高可用文件系統(tǒng)協(xié)同工作.如果你正在使用像 Cassandra 這樣的 NoSQL 系統(tǒng),你將了解到它擁有一個和 HDFS 兼容的文件系統(tǒng).基于某個特定文件系統(tǒng)來構(gòu)建 NoSQL 系統(tǒng)既有好處也有不足.

將 NoSQL 數(shù)據(jù)庫與分布式文件系統(tǒng)結(jié)合有以下優(yōu)勢.

• 重用可靠的組件——從時間和成本上考慮,重用已構(gòu)建好并完成測試的組件非常有意義.NoSQL 系統(tǒng)不需要重復實現(xiàn)分布式文件系統(tǒng)已實現(xiàn)的功能.另外,組織也許已經(jīng)有了相應的基礎設施和經(jīng)過培訓并知道如何部署配置這些系統(tǒng)的員工.
• 可定制的文件夾級別可用性——多數(shù)分布式文件系統(tǒng)可以實現(xiàn)文件夾級別的可用性配置.與使用存在單點故障問題的本地文件系統(tǒng)存儲輸入輸出數(shù)據(jù)集不同,這些系統(tǒng)可以配置為在多個地方存儲數(shù)據(jù),一般的默認配置是存儲到 3 個不同地方.這就意味著只有當 3 個節(jié)點同時崩潰時,客戶端請求才會失敗.而發(fā)生這種情況的概率對于多數(shù)服務級別來說已經(jīng)足夠了.
• 機架和站點感知——分布式文件系統(tǒng)軟件在設計中已經(jīng)考慮到了計算機集群在數(shù)據(jù)中心的位置分布因素.基于位于同一機架上的節(jié)點間會有更高帶寬的假設,在部署文件系統(tǒng)時,可以指明哪些節(jié)點位于同一個機架.機架也可以設置在不同數(shù)據(jù)中心,這樣文件系統(tǒng)就能在某個數(shù)據(jù)中心宕機后迅速地將數(shù)據(jù)復制到位于遠程數(shù)據(jù)中心機架的節(jié)點上.

將 NoSQL 數(shù)據(jù)庫與分布式文件系統(tǒng)結(jié)合還有以下缺點.

• 移植性較低——某些分布式文件系統(tǒng)在 UNIX 或 Linux 系統(tǒng)上的運行效果最好.將這些文件系統(tǒng)移植到像 Windows 這樣的其他操作系統(tǒng)上可能并不具可行性.如果確實想在 Windows 上運行,那可能就需要添加一個額外的虛擬機層,而這將造成性能的損失.
• 設計和部署較為耗時——部署一個具有優(yōu)秀設計的分布式文件系統(tǒng)時,探索出合適的文件夾結(jié)構(gòu)也許就會花費不少時間.文件夾中的所有文件都共享像復制因子這樣的屬性.如果使用創(chuàng)建日期作為文件夾名字,可能可以根據(jù)文件存在的日期(如兩年以上)來降低該文件的復制個數(shù).
• 學習曲線較為陡峭——員工需要去學習部署和管理一個分布式文件系統(tǒng).另外,還需要對這些系統(tǒng)進行監(jiān)控和備份敏感數(shù)據(jù).

案例研究：將 HDFS 作為一個高可用的文件系統(tǒng)存儲主數(shù)據(jù)

HDFS 通常能夠可靠地存儲 GB 級到 TB 級的海量文件,同時,HDFS 還可以調(diào)整復制配置以支持單文件級別的復制策略.默認情況下,HDFS 中的多數(shù)文件都擁有 3 個復制副本.這意味著組成這些文件的數(shù)據(jù)塊將備份存儲在 3 個不同的節(jié)點上.一個簡單的 HDFS shell 命令就可以更改任何 HDFS 文件或文件夾的備份數(shù).有兩個原因可能需要提高 HDFS 中文件的復制因子數(shù)配置.

• 降低數(shù)據(jù)變得不可訪問的可能——例如,如果依賴這個數(shù)據(jù)的數(shù)據(jù)服務要提供 5 個 9 的可用性保障,那么你可能會想把復制因子數(shù)從 3 提高到 4 或 5.
• 提高讀取并發(fā)——如果一個文件有大量的并發(fā)讀請求,可以增大復制因子使更多的節(jié)點可以響應這些請求.

降低備份數(shù)的主要原因一般是磁盤空間將被耗盡或是不再要求需要高復制數(shù)的服務級別.如果擔心磁盤空間將被耗盡,那么在數(shù)據(jù)不可訪問造成的損失較低且讀取需求不嚴格的情況下,可以減小復制因子.另一方面,讓復制數(shù)隨著數(shù)據(jù)存儲日期的變長而減小也比較常見.例如,超過 2 年的數(shù)據(jù)可能只有 2 個備份,而超過 5 年的數(shù)據(jù)就只有 1 個備份.

HDFS 提供的較好特性之一就是機架感知.機架感知功能可以根據(jù)節(jié)點在物理機架上的放置方式以及在一個機架內(nèi)部網(wǎng)絡中的連接方式對 HDFS 節(jié)點進行邏輯分組.位于同一個物理機架的節(jié)點之間通常擁有更高的帶寬連接,而且使用這種網(wǎng)絡能夠?qū)?shù)據(jù)和其他共享網(wǎng)絡進行隔離.下圖展示了這種結(jié)構(gòu).

HDFS 通常能夠可靠地存儲 GB 級到 TB 級的海量文件,同時,HDFS 還可以調(diào)整復制配置以支持單文件級別的復制策略.默認情況下,HDFS 中的多數(shù)文件都擁有 3 個復制副本.這意味著組成這些文件的數(shù)據(jù)塊將備份存儲在 3 個不同的節(jié)點上.一個簡單的 HDFS shell 命令就可以更改任何 HDFS 文件或文件夾的備份數(shù).有兩個原因可能需要提高 HDFS 中文件的復制因子數(shù)配置.

• 降低數(shù)據(jù)變得不可訪問的可能——例如,如果依賴這個數(shù)據(jù)的數(shù)據(jù)服務要提供 5 個 9 的可用性保障,那么你可能會想把復制因子數(shù)從 3 提高到 4 或 5.
• 提高讀取并發(fā)——如果一個文件有大量的并發(fā)讀請求,可以增大復制因子使更多的節(jié)點可以響應這些請求.

降低備份數(shù)的主要原因一般是磁盤空間將被耗盡或是不再要求需要高復制數(shù)的服務級別.如果擔心磁盤空間將被耗盡,那么在數(shù)據(jù)不可訪問造成的損失較低且讀取需求不嚴格的情況下,可以減小復制因子.另一方面,讓復制數(shù)隨著數(shù)據(jù)存儲日期的變長而減小也比較常見.例如,超過 2 年的數(shù)據(jù)可能只有 2 個備份,而超過 5 年的數(shù)據(jù)就只有 1 個備份.

HDFS 提供的較好特性之一就是機架感知.機架感知功能可以根據(jù)節(jié)點在物理機架上的放置方式以及在一個機架內(nèi)部網(wǎng)絡中的連接方式對 HDFS 節(jié)點進行邏輯分組.位于同一個物理機架的節(jié)點之間通常擁有更高的帶寬連接,而且使用這種網(wǎng)絡能夠?qū)?shù)據(jù)和其他共享網(wǎng)絡進行隔離.下圖展示了這種結(jié)構(gòu).

亞馬遜的 DynamoDB 論文是 NoSQL 運動中最具影響力的論文之一.這篇論文詳細地介紹了亞馬遜拋棄關(guān)系型數(shù)據(jù)庫管理系統(tǒng)設計轉(zhuǎn)而使用自己定制的分布式計算系統(tǒng)來滿足他們的網(wǎng)頁購物車對橫向擴展和高可用性需求的細節(jié).

最初,亞馬遜并沒有開源 DynamoDB.然而,盡管缺少源代碼,這篇 DynomaDB 論文還是對諸如 Cassandra、Redis 和 Riak 等其他 NoSQL 系統(tǒng)產(chǎn)生了深遠影響.在 2012 年 2 月,亞馬遜將 DynamoDB 開放為數(shù)據(jù)庫服務供其他開發(fā)者使用.這個案例研究將回顧亞馬遜的 DynamoDB 服務以及將它作為全托管、高可用、可擴展的數(shù)據(jù)庫服務的方法.

讓我們從介紹 DynamoDB 的高層特性開始.Dynamo 的關(guān)鍵革新點是它能夠快速且精確地調(diào)整吞吐量.這項服務能夠可靠地承載大量的讀寫事務,并且可以通過調(diào)整網(wǎng)頁上的配置完成分鐘級別的性能調(diào)整.下圖展示了它的用戶界面的一個示例.

亞馬遜的 DynamoDB 數(shù)據(jù)表吞吐量預設.通過修改讀容量單位或?qū)懭萘繂挝?可以將數(shù)據(jù)庫中的每張表調(diào)整到滿足容量需求的合適值.亞馬遜還提供了計算應用容量需求的工具

DynamoDB 管理著節(jié)點的使用數(shù)量和節(jié)點間負載均衡的策略.亞馬遜也提供了 API 接口可以根據(jù)負載監(jiān)控系統(tǒng)的結(jié)果進行編程調(diào)整預見到的吞吐量.整個過程均不需要運維人員的介入.而且每月的亞馬遜賬單會根據(jù)這些參數(shù)修改進行調(diào)整.

為了開發(fā) DynamoDB 服務,亞馬遜使用了許多復雜的算法在數(shù)萬臺服務器中實現(xiàn)均衡可靠地分發(fā)讀寫事務.另外,DynamoDB 的獨特之處還在于它是完全部署在固態(tài)硬盤(SSD)上的最初幾個系統(tǒng)之一,而使用 SSD 讓 DynamoDB 有了一個可預測的服務級別.

DynamoDB 的目標之一是提供穩(wěn)定在幾毫秒延遲內(nèi)的讀取響應.全部使用 SSD 意味著 DynamoDB 根本不需要考慮磁盤讀取延遲.最終結(jié)果就是用戶的所有 GET 和 PUT 操作均能夠得到穩(wěn)定的響應,而使用基于 DynamoDB 中數(shù)據(jù)進行渲染的網(wǎng)頁也會比其他基于磁盤數(shù)據(jù)庫中數(shù)據(jù)的網(wǎng)頁快.

DynamoDB 的 API 提供細粒度的讀取一致性控制.開發(fā)人員可以選擇從本地節(jié)點讀取一個中間結(jié)果(稱為最終一致性)的方式,或是較慢但確保一致性(guaranteed consisten)的數(shù)據(jù)讀取方式.這種確保一致性的讀取會花費稍長的時間來確保讀取數(shù)據(jù)的節(jié)點保存有最新的數(shù)據(jù)副本.如果應用知道請求的數(shù)據(jù)沒有改動,那么直接讀取會比較快.

這種讀取數(shù)據(jù)的細粒度控制是利用對一致性需求的理解來調(diào)整應用的絕好例子.需要重點強調(diào)的是,總是可以強制要求讀取結(jié)果一致,但對基于 SQL 的數(shù)據(jù)服務來說,這一需求會是個挑戰(zhàn),因為在分布式系統(tǒng)上執(zhí)行的 SQL 并沒有“在查找之前保持數(shù)據(jù)一致”的功能.

DynamoDB 非常適合于有彈性需求的組織.只為用到的服務付費的策略是節(jié)省服務器管理開銷的主要方法.然而,當確實需要擴展時,DynamoDB 也提供滿足業(yè)務快速增長需求的擴展空間.DynamoDB 還提供了可擴展的轉(zhuǎn)化彈性 MapReduce 支持.這就意味著在需要執(zhí)行可擴展的提取、轉(zhuǎn)化、裝載(ETL)過程時,可以快速地將海量數(shù)據(jù)移進移出 DynamoDB.

到現(xiàn)在為止,我們已經(jīng)介紹了 NoSQL 系統(tǒng)用來實現(xiàn)高可用性的多種策略.接下來,讓我們了解兩個有著高可用性方面良好口碑的 NoSQL 產(chǎn)品.

案例研究：使用 Apache Cassandra 作為高可用的列族存儲

這個案例研究將介紹 Apache Cassandra 數(shù)據(jù)庫.它是一個在可擴展性和高可用性兩方面均有良好口碑的 NoSQL 列族存儲.即使在寫入高負載的情況下,它也能為用戶保證數(shù)據(jù)服務的高可用性.Cassandra 是純對等分布式模型的早期實現(xiàn)者.它的集群中的所有節(jié)點均具有完全一致的功能,且客戶端可以在任意時間點向任意一個節(jié)點寫入數(shù)據(jù).因為 Cassandra 集群中不存在任何單獨的主節(jié)點,所以它的集群也就沒有所謂的單點故障,因此也就不需要再去部署測試額外的故障轉(zhuǎn)移節(jié)點.Apache Cassandra 本身是一個 NoSQL 技術(shù)的有趣結(jié)合體,所以有時也將它稱為受 Dynamo 靈感啟發(fā)的 BigTable 實現(xiàn).

除了它健壯的對等模型,Cassandra 還將大量心思放在了集群的易部署性和讀寫一致性級別的易配置性上.下表展示了完成復制級別配置后,它所能提供的多種寫入一致性級別設置.

用于指定 Cassandra 表寫入一致性的代碼.Cassandra 中的每張表在創(chuàng)建時就需要設置好滿足一致性級別需求的配置.而且還能隨時修改這些配置,Cassandra 也會根據(jù)修改自動地更新配置.讀取一致性方面也有類似的配置.

接下來,需要考慮的是一個讀取事務中某個節(jié)點變得不可用時的策略.怎樣指定返回新數(shù)據(jù)前需要檢查的節(jié)點數(shù)?只檢查一個節(jié)點可以使請求快速返回,但得到的數(shù)據(jù)可能已經(jīng)過期.而檢查多個節(jié)點可能會多花費數(shù)毫秒,但能確保獲取到數(shù)據(jù)的最新版本.最好的方法是讓客戶端指定和前面介紹的寫入一致性代碼類似的讀取一致性代碼.在讀取數(shù)據(jù)時,Cassandra 客戶端可以根據(jù)需求從 ONE、TWO、THREE、QUORUM、LOCAL_QUORUM、EACH_QUORUM 和 ALL 中選擇合適的代碼.甚至可以使用 EACH_QUORUM 在返回數(shù)據(jù)前檢查位于世界各地的多個數(shù)據(jù)中心.

接下來,將介紹部署配置 Cassandra 集群之前需要理解的具體配置項.

在 Cassandra 中配置數(shù)據(jù)和節(jié)點間的映射

在關(guān)于一致性散列的討論中,我們介紹了在集群中使用散列來均勻分發(fā)數(shù)據(jù)的技術(shù).Cassandra 使用了相同的技術(shù)來完成數(shù)據(jù)的均勻分發(fā).在深入理解 Cassandra 的實現(xiàn)方式之前,讓我們先介紹一些 Cassandra 中的關(guān)鍵術(shù)語和定義.

1) 行鍵

行鍵(rowkey)是一個數(shù)據(jù)行的標識符.Cassandra 會對這個值進行散列并根據(jù)得到的散列值將數(shù)據(jù)存放到一個或多個節(jié)點上.行鍵是用來決定數(shù)據(jù)存放節(jié)點的唯一數(shù)據(jù)結(jié)構(gòu),這個過程將不會用到任何列數(shù)據(jù).設計好行鍵結(jié)構(gòu)是保證相似數(shù)據(jù)聚合在一起以提供高速讀取的關(guān)鍵步驟.

2) 分區(qū)

分區(qū)(partitioner)是根據(jù)鍵指定一行數(shù)據(jù)存放節(jié)點的策略.默認策略是隨機選擇一個節(jié)點.Cassandra 使用鍵的 MD5 散列值作為數(shù)據(jù)行的一致性散列值,這樣就使得數(shù)據(jù)能夠隨機但均勻地分發(fā)到所有節(jié)點上.另一個選擇則是使用行鍵中實際的字節(jié)(而非行鍵的散列值)來決定數(shù)據(jù)存放的節(jié)點.

3) 鍵空間

鍵空間(keyspace)是決定一個鍵如何在節(jié)點上復制的數(shù)據(jù)結(jié)構(gòu).默認情況下,可能會將需要更高級別可用性的數(shù)據(jù)的復制數(shù)設置為 3.

Cassandra 鍵空間通常可以看作一個環(huán)的形式,如下圖所示.

使用 SimpleStrategy 配置復制 Cassandra 鍵空間的示例.數(shù)據(jù)項 A1、B1、C1 和 D1 被寫入了一個復制因子設為 3、由 4 個節(jié)點組成的集群里.每個數(shù)據(jù)項都被寫到 3 個不同節(jié)點上.在某個數(shù)據(jù)項完成第一個節(jié)點寫入后,Cassandra 將按順時針方向順序?qū)ふ?2 個額外的節(jié)點繼續(xù)寫入該數(shù)據(jù)項.

Cassandra 允許根據(jù)鍵空間的屬性對復制策略進行微調(diào).在向 Cassandra 系統(tǒng)中添加任意一行數(shù)據(jù)時,必須將這行數(shù)據(jù)和鍵空間關(guān)聯(lián)起來.每個鍵空間都允許配置修改該行的復制因子.下圖展示了一個鍵空間定義的示例.

Cassandra 配置復制策略的示例.復制策略是鍵的一個屬性,指明了所在網(wǎng)絡類型和對應鍵復制數(shù).

使用這個策略能夠均勻地將數(shù)據(jù)行分發(fā)到集群的所有節(jié)點上,從而消除系統(tǒng)瓶頸.雖然可以使用鍵中特定的幾位來關(guān)聯(lián)鍵空間,但我們強烈建議不使用這種方式.因為它可能導致集群中出現(xiàn)熱點節(jié)點并使集群管理復雜化.而這種方式最主要的局限是如果更改了分區(qū)算法,就不得不重新保存并恢復整個數(shù)據(jù)集.

當擁有多個機架或多個數(shù)據(jù)中心時,也許需要更改這個算法來保證在返回寫入確認消息前,數(shù)據(jù)已經(jīng)寫入了多個機架甚至是多個數(shù)據(jù)中心中.如果將分發(fā)策略從 SimpleStrategy 改為 NetworkTopologyStrategy,Cassandra 將會遍歷鍵空間環(huán)直到找到位于不同機架或數(shù)據(jù)中心的節(jié)點.

因為 Cassandra 擁有一個完整的對等部署模型,所以它看起來很適合那些期望使用同時具有高可用性和可擴展性的列族系統(tǒng)的組織.下一個案例研究將探討 Couchbase 2.0 使用 JSON 文檔存儲實現(xiàn)對等模型的方法.

案例研究：使用 Couchbase 作為高可用文檔數(shù)據(jù)庫

Couchbase 2.0 是一個使用了和其他 NoSQL 系統(tǒng)相同復制模式的 JSON 文檔數(shù)據(jù)庫.

Couchbase 與 CouchDB

Couchbase 技術(shù)不應該和 Apache CouchDB 混為一談.雖然兩者都是開源技術(shù),但它們是兩個獨立的、有著不同特性以及用來支持不同應用開發(fā)和場景的開源項目.在底層結(jié)構(gòu)上,Couchbase 和最初的 Memcached 項目的共同點比與最初的 CouchDB 項目的共同點更多.雖然 Couchbase 和 CouchDB 使用同樣的生成 JSON 文檔的算法,但具體的實現(xiàn)方式卻不相同.

與 Cassandra 類似,Couchbase 也使用所有節(jié)點提供相同服務的對等分布式模型,以消除單點故障出現(xiàn)的可能.但與 Cassandra 不同的是,Couchbase 采用的是可以根據(jù)文檔內(nèi)容查詢的文檔存儲而非列族存儲.另外,Couchbase 也使用了鍵空間這一概念將鍵范圍和每個節(jié)點關(guān)聯(lián)起來.

下圖展示了部署在多個數(shù)據(jù)中心的 Couchbase 服務器中的組件.Couchbase 將文檔集合存儲在被稱為桶(bucket)的容器中.這些桶的配置管理和文件系統(tǒng)中的文件夾非常類似.桶的類型包括兩種：緩存在內(nèi)存中的桶(存儲在內(nèi)存中且會被清除)和存儲在磁盤上并配置了復制的 Couchbase 桶.一個 Couchbase JSON 文檔會被寫入一個或多個磁盤上.針對高可用性系統(tǒng)的討論,我們將主要關(guān)注 Couchbase 桶.

Couchbase 中高可用的文檔.Couchbase 桶是配置用來實現(xiàn)高可用性的文檔邏輯集合.Couchbase 客戶端通過集群映射配置找到存儲在當前活動節(jié)點上的文檔(第 1 步).如果數(shù)據(jù)服務器 1 不可用,集群映射配置將使存儲在數(shù)據(jù)服務器 2 上的 doc1 的備份成為當前生效的版本(第 2 步).如果美國西部數(shù)據(jù)中心宕機,客戶端將會使用跨數(shù)據(jù)中心備份(XDCR)并使存儲在位于美國東部地區(qū)的數(shù)據(jù)服務器 3 上的副本成為生效版本(第 3 步)

在內(nèi)部,Couchbase 使用了一個被稱為 vBucket(虛擬桶)的概念.這個概念關(guān)聯(lián)了一個基于散列值切分出來的鍵空間的某個或某幾個部分.Couchbase 的鍵空間和 Cassandra 中的鍵空間類似.但在數(shù)據(jù)存儲時,它的鍵空間管理對外部是透明的.

需要注意的是,一個虛擬桶并不只是包含某個鍵空間范圍,而是可能會包含許多非連續(xù)的鍵空間.值得慶幸的是,用戶并不需要考慮鍵空間的管理或是虛擬桶的工作原理.Couchbase 客戶端僅僅是和這些桶進行交互,而讓 Couchbase 服務器去考慮應該從哪個節(jié)點上找到存儲在某個桶中的數(shù)據(jù).將桶和虛擬桶區(qū)分開來是 Couchbase 實現(xiàn)橫向擴展的主要方式.

通過使用集群映射表中的信息,Couchbase 會在主節(jié)點和備份節(jié)點上各存儲一份數(shù)據(jù).如果 Couchbase 集群中的任何節(jié)點失效,該節(jié)點就會被打上一個故障轉(zhuǎn)移的標記,而集群隨之會根據(jù)這標記更新集群映射表.所有指向該節(jié)點的數(shù)據(jù)請求都會被轉(zhuǎn)向到備份節(jié)點.

在某個節(jié)點失效與對應備份節(jié)點接管后,用戶通常會開始一個重平衡操作——向集群中添加新節(jié)點以使集群恢復之前的容量.重平衡操作將更新虛擬桶和節(jié)點間的映射信息并使之生效.在重平衡期間,虛擬節(jié)點會被均勻地在節(jié)點間進行重分發(fā)以此最小化數(shù)據(jù)在集群中的移動.一旦某個虛擬桶在新節(jié)點上被重新創(chuàng)建,集群會自動禁用之前節(jié)點上的虛擬桶并啟用新節(jié)點上的虛擬桶.

Couchbase 提供了使 Couchbase 集群在整個數(shù)據(jù)中心宕機的情況下也能不間斷運行的功能.針對橫跨了多個數(shù)據(jù)中心的系統(tǒng)來說,Couchbase 提供了一個被稱為跨數(shù)據(jù)中心復制(cross data center replication,XDCR)的功能.這個功能使數(shù)據(jù)可以自動地備份到遠程數(shù)據(jù)中心并在兩個中心里均保持可用.如果一個數(shù)據(jù)中心發(fā)生宕機,另一個數(shù)據(jù)中心可以負責承擔其負載并持續(xù)對外提供服務.

Couchbase 的最強特性之一是其內(nèi)建的高精度監(jiān)控工具.下圖展示了其監(jiān)控工具的一個示例.

文/來自高可用架構(gòu)微信公眾號

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4523.html