ZooKeeper持久化原理是什么

這篇文章主要介紹“ZooKeeper持久化原理是什么”，在日常操作中，相信很多人在ZooKeeper持久化原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”ZooKeeper持久化原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

ZK 的數據與存儲中，有幾個特別關注點：

1. 內存數據與磁盤數據間的關系：

• 恢復內存數據，恢復現場

• 數據同步：集群內，不同節點間的數據同步（另，內存中的提議緩存隊列 proposals）

• 磁盤數據，為什么同時包含：快照、事務日志？出于數據粒度的考慮

• 因此粒度很細，恢復現場時，能夠恢復到事務粒度上

• 因為生成快照的時間間隔太大，即，快照的粒度太粗了

• 如果只包含快照，那恢復現場的時候，會有數據丟失，

• 事務日志，針對每條提交的事務都會 flush 到磁盤，

• 內存數據，是真正提供服務的數據

• 磁盤數據，作用：

2. 快照生成的時機：基于閾值，引入隨機因素

• countLog 為累計執行事務個數

• snapCount 為配置的閾值

• randRoll 為隨機因素（取值：0～snapCount/2）

• 因為 dump snapshot 耗費大量的 磁盤 IO、CPU，

• 所有節點同時 dump 會嚴重影響集群的對外服務能力

• 解決的關鍵問題：避免所有節點同時 dump snapshot，

• countLog > snapCount/2 + randRoll，其中：

3. ZK 的 快照文件是 Fuzzy 快照，不是精確到某一時刻的快照，而是某一時間段內的快照

• RDB 文件是精確的快照，原因：進程之間內存空間隔離

• 系統內核使用「寫時復制」（Copy-On-Write）技術，節省大量內存空間

• 線程之間共享內存空間，導致 Fuzzy 快照

• 這就要求 ZK 的所有事務操作是冪等的，否則產生數據不一致的問題

• 實際上 ZK 的所有操作都是冪等的

• ZK 使用「異步線程」生成快照：

• 類比：Redis 中使用「異步進程」生成快照 RDB（Redis Dump Binary）

https://blog.csdn.net/varyall/article/details/79564418

• 若在Zookeeper進行快照的過程中,接收了客戶端的請求,此時會將該請求應用到DataTree嗎?

• Zookeeper是調用zks.takeSnapshot()生成快照文件的,

• 這個方法及其底層的方法并沒有對DataTree加鎖,

• 因此生成快照文件并不是一個原子性的操作,

• 所以快照執行開始到快照執行結束期間發生的事務也會應用到DataTree中,

• 也會持久化到快照文件中,也即說明即使快照后綴名為n,此快照文件也有可能包含n+1,n+2這些事務的執行結果. 

• 若會,這會出現什么問題?如何解決? 

https://blog.csdn.net/jpf254/article/details/80769525

到此，關于“ZooKeeper持久化原理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！