詳解 ZooKeeper 數據持久化
- 2021 年 3 月 18 日
- 筆記
- HelloZooKeeper
本文作者：HelloGitHub-老荀
Hi，這裡是 HelloGitHub 推出的 HelloZooKeeper 系列，免費開源、有趣、入門級的 ZooKeeper 教程，面向有編程基礎的新手。
前一篇文章我們介紹了 ZK 是如何進行選舉的，這篇我們開始學習 ZK 是如何將數據持久化到磁碟中的。
一、優秀員工小S(Sync)
我們通過之前的文章有介紹過，小S(Sync) 負責對辦事處的數據進行歸檔，所以今天他就是我們的主角，讓我們一起深入了解他的日常工作吧
為了喚醒大家的遠古記憶，我放一張之前的圖片
今天我們會重點講一下圖中的藍色部分，不過在此之前還是得先從整體架構上介紹下 ZK 的數據管理，ZK 的數據大致是分為了兩部分，一個是記憶體，一個就是磁碟文件。
1.1 記憶體
雖然今天我們的主角是磁碟文件，但是記憶體還是稍微再提一下下，幫助大家記憶的同時也能有一個比較全面的視角去認知 ZK 整體的數據管理。
ZK 在記憶體中的存儲就是之前故事中有提到的兩個賬本：小紅本和小黃本。如果排除作為回調通知記錄的小黃本，那 ZK 的記憶體中就是小紅本對應的哈希表而已，但是小黃本中的數據依然非常重要，所以需要將兩者作為整體一起看待，以及之前我有說過 小F(Final) 掌管了這兩個賬本，作為業務處理的最後一個負責人，小S(Sync) 從時間上來說是優先於 小F(Final) 先處理的，所以 ZK 的設計是優先將數據存入磁碟，再去修改記憶體中的數據保證儘可能的提升數據的可靠性。下面我們繼續了解磁碟文件（還真就提一下下！）
1.2 磁碟文件
ZK 的開發者給 ZK 設計了兩種磁碟文件，對應的路徑分別是 zoo.cfg 配置中的 dataDir 和 dataLogDir 這兩項目錄的配置。為了之後的描述清楚，我給這兩種磁碟文件起了名字： dataDir 對應 snapshot，dataLogDir 對應 log，log 就是的是 小S(Sync) 工作中的歸檔，snapshot 就是的是 小S(Sync) 工作中的快照。
log 是負責順序記錄每一個寫請求到文件，snapshot 則是直接將整個記憶體對象持久化至文件中。假設我現在 zoo.cfg 的配置是這樣：
dataDir=/tmp/zookeeper/snapshot
dataLogDir=/tmp/zookeeper/log
當 ZK 啟動後會基於上面兩個路徑繼續創建 version-2 子路徑，之後的文件都會在該子路徑下創建
/tmp
└── zookeeper
├── snapshot
└── version-2
└── ...
└── log
└── version-2
└── ...
二、文件的創建和寫入
兩種文件分別是在什麼時候被寫入磁碟的呢？寫入的內容又是哪些呢？我們接下來對兩種文件一一進行分析。
2.1 log 文件
log 文件名的格式是這樣 log.{zxid} zxid 對應當時創建該文件時的最大 zxid，假設現在創建時 zxid 為 0，那目錄結構會是這樣：
/tmp
└── zookeeper
└── log
└── version-2
└── log.0
這個 log.0 文件創建的時機你也可以簡單的理解為當服務端收到第一個寫請求的時候，而且當創建完成後，並不能直接將數據寫入，而是要先寫一些文件頭的欄位，比如大名鼎鼎的魔數，版本號等元資訊。
而 log 文件的魔數是 ZKLG（4 個位元組），版本號固定為 2（4 個位元組），還要記錄一個 dbId 固定為 0（8 個位元組） （當前沒用，可能之後會派用處吧），所以前 16 個位元組是固定這樣的：
Z K L G 2 0
5A4B4C47 00000002 00000000 00000000
那之後的業務數據是如何記錄的呢？
每一個寫請求都可以分為四個部分：校驗和、請求頭、請求數據、簽名，校驗和是通過後面三個欄位計算出來的，小S 每次收到寫請求後都會按照這樣的順序將對應請求的四個欄位寫入 log 文件，由於不同的業務請求數據不固定，而且數據長度也比較大，這裡就不給大家展示具體的值（如果大家想要知道這硬核的存儲過程，不妨給我留言，我以後單獨做下，嘗試逐個位元組解釋）
然後是 zookeeper.txnLogSizeLimitInKb 這個環境變數配置，默認是 -1，這個配置限制了 log 單個文件大小（單位是 KB），每次 小S(Sync) 歸檔的時候（圖中右下角粉色部分「是否歸檔」），將數據統一刷到磁碟後，如果用戶手動配置了該參數，就會檢查當前 log 文件大小是否超過了該參數大小，如果超過了就會進行 rollLog，相當於下一次的寫請求會創建一個新的 log 文件。除此之外，當 小S(Sync) 每次快照的時候會強制執行一次 rollLog。
2.2 snapshot 文件
snapshot 文件名的格式是這樣 snapshot.{zxid} zxid 對應當是創建該文件時的最大 zxid，假設現在創建是最大 zxid 是 0，那目錄結構會是這樣：
/tmp
└── zookeeper
└── snapshot
└── version-2
└── snapshot.0
而關於是否快照（圖中中間區域粉色部分「是否快照」），之前有簡單介紹過是和隨機數有關，這次我們深入了解下。
首先有兩個配置 zookeeper.snapCount （默認 100000）和 zookeeper.snapSizeLimitInKb（默認 4194304 單位是KB，相當於 4 GB）在啟動後會基於這兩個配置分別生成兩個隨機數，假設上述的配置是按照默認的設置，這兩個隨機數的範圍就是：
randRoll = [0, 50000]
randSize = [0, 4194304 * 1024 / 2]
可以簡單的認為就是上述兩個配置的一半之內的隨機數，至於 randSize 為什麼要乘以 1024 因為最終文件計算大小是以 byte 作為單位的。
而是否快照就是取決於上面兩個隨機數，有兩個條件：
- 當前寫請求的數量達到了
zookeeper.snapCount的一半並加上randRoll的數量 - 當前 log 文件的大小達到了
zookeeper.snapSizeLimitInKb的一半並加上randSize的大小
上述條件滿足任意一個條件後就會重置上面的兩個隨機數，並開始生成快照，生成快照這個過程是啟動一個子執行緒去創建的。
snapshot 和 log 還有個不同的地方就是，snapshot 文件 ZK 提供了三種不同的壓縮實現，GZIP、SNAPPY、CHECKED，通過 zookeeper.snapshot.compression.method 進行配置，默認是 CHECKED，就是原始按照位元組順序寫入，另外兩個這裡就不展開了。那我們接下來看看 snapshot 文件是怎麼記的吧。
和 log 文件一樣，也要先記一些文件的頭部欄位，而 snapshot 文件的魔數是 ZKSN（4 個位元組），版本號固定為 2（4 個位元組），還要記錄一個 dbId 固定為 -1（8 個位元組） （當前沒用，可能之後會派用處吧），所以前 16 個位元組是固定這樣的：
Z K S N 2 -1
5A4B534E 00000002 FFFFFFFF FFFFFFFF
然後緊跟其後的部分客戶端的會話資訊，客戶端的數量，然後循環記錄每一個客戶端的 sessionId、超時時間，然後是小紅本里的所有資訊了包括但不限於 ACL，節點的統計數據，節點的數據，子節點的資訊等。最後一部分就是校驗和和簽名。和 log 一樣，如果大家有興趣的話，我之後單獨再做一篇逐個位元組講解的。
三、從文件中恢復
如果只是單單存文件，那這文件也沒什麼用，所以文件另一個重要用途就是幫助 ZK 恢復服務端的資訊。
在 ZK 啟動的時候就會嘗試讀取 dataDir 和 dataLogDir 這兩個目錄下的文件，假設在這兩個路徑下的文件是：
/tmp
└── zookeeper
├── snapshot
└── version-2
└── snapshot.5
└── snapshot.37
└── snapshot.100
└── log
└── version-2
└── log.0
└── log.6
└── log.38
└── log.90
└── log.108
我這裡例子中的文件名的後綴數字是我隨便舉例只是為了說明恢復的過程，實際未必是這樣，切記。
現在 ZK 服務端啟動後，會先從 snapshot 的目錄中找到 zxid 最大的那個文件，然後根據它的內容恢復 小紅本
恢復完後就會去 log 文件目錄下尋找所有比 100 要大的 log 文件以及比 100 要略小一點的 log 文件，本例子中就是 log.90 和 log.108 這兩個文件。
你可能會問為什麼要找小於 100 的 log.90 這個文件呢？因為文件名中的 90 只是說明這個文件建立的時候，最大的 zxid 是 90，但是文件中記錄的寫請求是很有可能會大於 100 的，所以 log.90 也需要被找到。
然後就是從 log.90 這個文件開始恢復，先從 zxid 比 100 大的寫請求開始讀取並執行該寫請求，然後繼續讀取 log.108，等待所有符合條件的 log 文件讀取後，整個 ZK 的數據就恢復完成了。
四、總結
今天我們介紹了關於 ZK 持久化的知識：
- ZK 會持久化到磁碟的文件有兩種：log 和 snapshot
- log 負責記錄每一個寫請求
- snapshot 負責對當前整個記憶體數據進行快照
- 恢複數據的時候，會先讀取最新的 snapshot 文件
- 然後在根據 snapshot 最大的 zxid 去搜索符合條件的 log 文件，再通過逐條讀取寫請求來恢復剩餘的數據
今天的內容還是比較簡單的，為我們下一篇文章打好了基礎～下一篇我們開始介紹之前選舉中沒有介紹的內容：選舉完成後，Follower 和 Observer 是如何同 Leader 同步數據的？
老規矩，如果你有任何對文章中的疑問也可以是建議或者是對 ZK 原理部分的疑問，歡迎來倉庫中提 issue 給我們，或者來語雀話題討論。
