Hbase是一個強一致性數據庫，不是“最終一致性”數據庫，官網給出的介紹：

“Strongly consistent reads/writes: HBase is not an "eventually consistent" DataStore. This makes it very suitable for tasks such as high-speed counter aggregation.”

這里要先提一下分布式系統的CAP原理:
Consistency(一致性), 數據一致更新，所有數據變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容錯性) 可靠性

定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分布式系統，而是應該進行取舍。

1.首先來理解下一致性

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

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

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

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

• N — 數據復制的份數?
• W — 更新數據時需要保證寫完成的節點數?
• R — 讀取數據的時候需要讀取的節點數?

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

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

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

• 如果N=W,R=1，任何一個寫節點失效，都會導致寫失敗，因此可用性會降低，但是由于數據分布的N個節點是同步寫入的，因此可以保證強一致性。?
• 如果N=R,W=1，只需要一個節點寫入成功即可，寫性能和可用性都比較高。但是讀取其他節點的進程可能不能獲取更新后的數據，因此是弱一致性。這種情況下，如果W<(N+1)/2，并且寫入的節點不重疊的話，則會存在寫沖突 ?

2.HBase是強一致性系統?

Hbase具有以下特點

• 每個值只出現在一個REGION
• 同一時間一個Region只分配給一個Region服務器
• 行內的mutation操作都是原子的(原子性操作是指：如果把一個事務可看作是一個程序,它要么完整的被執行,要么完全不執行)。
• put操作要么成功，要么完全失敗。

聯系上文提到的一致性特點，可以得出HBase是強一致性系統的結論。

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

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

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

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

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

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

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

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

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

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

這里再提一下WAL的一致性

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

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

當前的sync()的實現是管道寫，也就是HDFS寫數據、生成副本的默認方式，這意味著當修改被寫入時，它會被發送到第一個DataNode進行存儲。一旦成功，第一個DataNode就會把修改發送到另一個DataNode來進行相同的工作。只有3個DataNode都已經確認了寫操作，客戶端才被允許繼續進行； 另一種存儲修改的方法是多路寫，也就是寫入被同時送到3臺機器上。當所有主機確認了寫操作后，客戶端才可以繼續。 兩種方法的優缺點： 管道寫需要時間去完成，所以它有很高的延遲，但是它能更好地利用網絡帶寬；多路寫有著比較低的延遲，因為客戶端只需要等待最慢的DataNode確認（假設其余都已成功確認）。但是寫入需要共享發送服務器的網絡帶寬，這對于有著很高負載的系統來說是一個瓶頸。 目前有正在進行的工作能讓HDFS支持上面兩種方式。

?

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

?

參考文獻

【1】http://kabike.iteye.com/blog/2168852?utm_source=tuicool

【2】http://www.blogjava.net/hello-yun/archive/2012/04/27/376744.html

【3】《HBase權威指南》Lars George著

總結

以上是生活随笔為你收集整理的HBase——强一致性详解的全部內容，希望文章能夠幫你解決所遇到的問題。

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