溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了HBase中強一致性的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
對于一致性，可以分為從客戶端和服務端兩個不同的視角。
從客戶端來看，一致性主要指的是多并發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何復制分布到整個系統，以保證數據最終一致。一致性是因為有并發讀寫才有的問題，因此在理解一致性的問題時，一定要注意結合考慮并發讀寫的場景。
從客戶端角度，多進程并發訪問時，更新過的數據在不同進程如何獲取的不同策略，決定了不同的一致性。對于關系型數據庫，要求更新過的數據能被后續的訪問都能看到，這是強一致性。如果能容忍后續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間后要求能訪問到更新后的數據，則是最終一致性
從服務端角度，如何盡快將更新后的數據分布到整個系統，降低達到最終一致性的時間窗口，是提高系統的可用度和用戶體驗非常重要的方面。對于分布式數據系統：
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，并且寫入的節點不重疊的話，則會存在寫沖突
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就降低一致性來提高可用性了。
一開始非常迷惑于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的時候數據才會真正被刪除。
感謝你能夠認真閱讀完這篇文章，希望小編分享的“HBase中強一致性的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
