ZooKeeper持久化原理

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

1. 內存數據與磁盤數據間的關係：
   • 內存數據，是真正提供服務的數據
   • 磁盤數據，做用：
     • 恢復內存數據，恢復現場
     • 數據同步：集羣內，不一樣節點間的數據同步（另，內存中的提議緩存隊列 proposals）
     • 磁盤數據，爲何同時包含：快照、事務日誌？出於數據粒度的考慮
       • 若是隻包含快照，那恢復現場的時候，會有數據丟失，
         • 由於生成快照的時間間隔太大，即，快照的粒度太粗了
       • 事務日誌，針對每條提交的事務都會 flush 到磁盤，
         • 所以粒度很細，恢復現場時，可以恢復到事務粒度上
2. 快照生成的時機：基於閾值，引入隨機因素
   • 解決的關鍵問題：避免全部節點同時 dump snapshot，
     • 由於 dump snapshot 耗費大量的 磁盤 IO、CPU，
     • 全部節點同時 dump 會嚴重影響集羣的對外服務能力
   • countLog > snapCount/2 + randRoll，其中：
     • countLog 爲累計執行事務個數
     • snapCount 爲配置的閾值
     • randRoll 爲隨機因素（取值：0～snapCount/2）
3. ZK 的 快照文件是 Fuzzy 快照，不是精確到某一時刻的快照，而是某一時間段內的快照
   • ZK 使用「異步線程」生成快照：
     • 線程之間共享內存空間，致使 Fuzzy 快照
     • 這就要求 ZK 的全部事務操做是冪等的，不然產生數據不一致的問題
     • 實際上 ZK 的全部操做都是冪等的
   • 類比：Redis 中使用「異步進程」生成快照 RDB（Redis Dump Binary）
     • RDB 文件是精確的快照，緣由：進程之間內存空間隔離
     • 系統內核使用「寫時複製」（Copy-On-Write）技術，節省大量內存空間

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