HBase中強一致性的示例分析

這篇文章主要介紹了HBase中強一致性的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

1.首先來理解下一致性

對于一致性，可以分為從客戶端和服務端兩個不同的視角。

從客戶端來看，一致性主要指的是多并發(fā)訪問時更新過的數(shù)據(jù)如何獲取的問題。從服務端來看，則是更新如何復制分布到整個系統(tǒng)，以保證數(shù)據(jù)最終一致。一致性是因為有并發(fā)讀寫才有的問題，因此在理解一致性的問題時，一定要注意結(jié)合考慮并發(fā)讀寫的場景。

從客戶端角度，多進程并發(fā)訪問時，更新過的數(shù)據(jù)在不同進程如何獲取的不同策略，決定了不同的一致性。對于關系型數(shù)據(jù)庫，要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到，這是強一致性。如果能容忍后續(xù)的部分或者全部訪問不到，則是弱一致性。如果經(jīng)過一段時間后要求能訪問到更新后的數(shù)據(jù)，則是最終一致性

從服務端角度，如何盡快將更新后的數(shù)據(jù)分布到整個系統(tǒng)，降低達到最終一致性的時間窗口，是提高系統(tǒng)的可用度和用戶體驗非常重要的方面。對于分布式數(shù)據(jù)系統(tǒng)：

• N — 數(shù)據(jù)復制的份數(shù) 

• W — 更新數(shù)據(jù)時需要保證寫完成的節(jié)點數(shù) 

• R — 讀取數(shù)據(jù)的時候需要讀取的節(jié)點數(shù) 

如果W+R>N，寫的節(jié)點和讀的節(jié)點重疊，則是強一致性。例如對于典型的一主一備同步復制的關系型數(shù)據(jù)庫，N=2,W=2,R=1，則不管讀的是主庫還是備庫的數(shù)據(jù)，都是一致的。

如果W+R<=N，則是弱一致性。例如對于一主一備異步復制的關系型數(shù)據(jù)庫，N=2,W=1,R=1，則如果讀的是備庫，就可能無法讀取主庫已經(jīng)更新過的數(shù)據(jù)，所以是弱一致性。

對于分布式系統(tǒng)，為了保證高可用性，一般設置N>=3。不同的N,W,R組合，是在可用性和一致性之間取一個平衡，以適應不同的應用場景。

• 如果N=W,R=1，任何一個寫節(jié)點失效，都會導致寫失敗，因此可用性會降低，但是由于數(shù)據(jù)分布的N個節(jié)點是同步寫入的，因此可以保證強一致性。 

• 如果N=R,W=1，只需要一個節(jié)點寫入成功即可，寫性能和可用性都比較高。但是讀取其他節(jié)點的進程可能不能獲取更新后的數(shù)據(jù)，因此是弱一致性。這種情況下，如果W<(N+1)/2，并且寫入的節(jié)點不重疊的話，則會存在寫沖突  

2.HBase是強一致性系統(tǒng) 

Hbase具有以下特點

• 每個值只出現(xiàn)在一個REGION

• 同一時間一個Region只分配給一個Region服務器

• 行內(nèi)的mutation操作都是原子的(原子性操作是指：如果把一個事務可看作是一個程序,它要么完整的被執(zhí)行,要么完全不執(zhí)行)。

• put操作要么成功，要么完全失敗。

聯(lián)系上文提到的一致性特點，可以得出HBase是強一致性系統(tǒng)的結(jié)論。

當某臺region server fail的時候，它管理的region failover到其他region server時，需要根據(jù)WAL log（Write-Ahead Logging）來redo(redolog，有一種日志文件叫做重做日志文件)，這時候進行redo的region應該是unavailable的，所以hbase降低了可用性，提高了一致性。設想一下，如果redo的region能夠響應請求，那么可用性提高了，則必然返回不一致的數(shù)據(jù)(因為redo可能還沒完成)，那么hbase就降低一致性來提高可用性了。

3.HBase的強一致性和HDFS的多副本

一開始非常迷惑于HBase的強一致性和HDFS的多副本是怎么協(xié)同的。

這一塊兒就需要對HBase和HDFS的讀寫數(shù)據(jù)流有個比較透徹的理解。

先假設HDFS的副本存儲策略，也就是dfs.replication的值為3（默認值就是3）

這樣所有存儲在HDFS上的文件都有3個副本。那么，HBase的存儲實例，也就是HFile也有3個副本。那么當某一個RegionServer崩潰時，并不用擔心數(shù)據(jù)的丟失，因為數(shù)據(jù)是存儲在HDFS上，哪怕崩潰的RegionServer所在的DataNode上有一個副本，在其他DataNode上也還有2個副本。

那么也許你要問，既然有3個副本，如何保證HBase的強一致性呢？

HFile是已經(jīng)持久化在磁盤上了，而HFile是不能改變的（這個時候暫時把刪除數(shù)據(jù)這個操作放到一邊，相關內(nèi)容請看下面的Note），一旦在某一個DataNode上生成一個HFile后就會異步更新到其他兩個DataNode上，這3個HFile是一模一樣的。

那也許你又要問，那我的數(shù)據(jù)是不斷更新當中啊！

更新的數(shù)據(jù)是放在Memstore，只有當Memstore里的數(shù)據(jù)達到閾值，或者時間達到閾值，就會flush到磁盤上，生成HFile，而一旦生成HFile就是不可改變的（compaction，split就是后話啦）。

這里再提一下WAL的一致性

WAL是Write-Ahead logging，這個是Memstore里的數(shù)據(jù)在RegionServer崩潰時得以恢復的保證。WAL的實現(xiàn)是HLog，HLog也是存儲在HDFS上的，所以HRegionServer崩潰了也不會導致HLog的丟失，它也有備份。

每一次更新都會調(diào)用寫日志的sync()方法，這個調(diào)用強迫寫入日志的更新都會被文件系統(tǒng)確認。

Note：當客戶端提交刪除操作的時候，數(shù)據(jù)不是真正的刪除，只是做了一個刪除標記（delete marker，又稱母被標記），表明給定航已經(jīng)被傷處了，在檢索過程中，這些刪除標記掩蓋了實際值，客戶端讀不到實際值。直到發(fā)生compaction的時候數(shù)據(jù)才會真正被刪除。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“HBase中強一致性的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業(yè)資訊頻道，更多相關知識等著你來學習!