從zookeeper的數據持久化與快速載入說起

在當前的軟體行業，持久化一直是一個熱門的話題;

比如：如何保證數據不丟失?

如何快速的載入數據，恢復應用服務?

當單節點故障，如何保證數據不丟失?

這些都是亟待解決的問題。

先從zookeeper的數據說起，zookeeper的數據在內存中是以樹形結構的datatree形式存在的，採用了兩種方式進行數據的持久化，一種是定期的snapshot;一種是增量事務日誌txnlog;

snapshot：記錄了整個內存中的數據，即datatree的序列化;

txnlog：實時記錄了所有訪問zookeeper的事務請求，包括create、setdata、setacl、delete等等操作;

如何保證數據不丟失?

在zookeeper客戶端請求zookeeper服務中，zookeeper的服務端首先是判斷這個請求是否是事務請求，如果是事務請求，那麼zookeeper服務端首先將這個請求記錄在增量事務日誌中，保證了其持久化，然後再進行更新內存數據datatree;在這個過程中，它也會去判斷是否生成snapshot，如果要生成snapshot，那麼就創建一個新的線程去干snapshot的事情;

如何快速的載入數據，恢復應用服務?

由於snapshot是定期生成的，所以它的數據可能不是最新的數據，如果我們只載入這個數據，難免會有漏數據，所以在zookeeper重啟後，它會先去找到最新且合法的snapshot，這裡有一個合法，其實就是校驗其文件的完整性;載入完了之後，其實就是載入了zookeeper的一大部分數據，這時候會返回當前處理的最新的zxid，然後去增量事務日誌中，找到大於等於zxid 1的事務記錄，這樣從這個記錄開始，直至讀取到文件結束，其實就完成了快速的載入數據。

如何保證單節點故障，不影響數據丟失呢?

zookeeper服務會在事務請求的時候，將事務請求轉發給每一個參與決議的節點，即leader和follower，然後收到半數以上的返回後，才會更新自己的數據，緊接著才會返回給客戶端響應;也就是在這個過程中一定有半數以上的節點完成了數據的持久化，這樣解決了單節點故障，不丟失數據;

總結

其實zookeeper的這種持久化方案，在很多基礎組件中都是如此的，比如很多資料庫的持久化方案等等;所以知曉這種方案，也可以舉一反三，希望這些知識對大家後續的工作中有所幫助!

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！