AppBoxFuture的存儲引擎依賴Raft一致性協議來保證各個分區副本的一致性，如果不處理Raft日志將不斷增長，因此需要特定的機制（定期或每處理一定數量的日志）來回收那些無用的日志數據。通過學習Raft協議內的Log Compaction，並參考TiKV等實現，作者初步實現了分區快照與日志截斷回收功能。
一、快照流程：
每個分區對應一個Raft組，由不同的Raft節點分布在集群的不同機器上，每個RaftNode都在循環處理Ready（如下圖所示）:
-
在達到快照創建條件時（上圖步驟6），即滿足一定周期（如6小時）且期間應用的已遞交日志數量達到閾值（如10000條），RaftNode通知對應的狀態機創建快照，這里主要是利用RocksDB的Snapshot及SstFileWriter將當前分區所涉及的KV數據寫入相應的sst文件內。在狀態機創建快照成功后，RaftNode通知對應的RaftStorage截斷並回收日志，由於目前Raft日志同樣使用RocksDB存儲，所以可以利用RocksDB的DeleteRange功能批量刪除無用的日志。
-
如果同一Raft組內的某一節點所在的機器Down機了較長的時間，在此期間此組內的Leader達到快照條件創建了快照並回收了日志。之后Down掉的機器重新啟動，Follower與Leader通信后要求追加Down機期間的日志，但Leader快照前的日志已刪除，Leader會發送Raft快照給Follower，這里需要注意的是Leader先發送狀態機創建的各個sst文件，都發送完了再發送RaftSnapshot消息。
-
Follower在收到快照消息時（上圖步驟3），先清理當前分區所涉及的所有舊數據，然后通知對應的狀態機恢復快照數據，這里主要是利用RocksDB的IngestExternalFile將各個sst文件快速導入存儲內。
創建與接收的快照文件目前存儲在運行時snapshot目錄內。
二、簡單測試：
1. 啟動集群並新建測試用實體模型
參考前篇“告別單體架構，迎接分布式時代”啟動一個新集群，並且登錄至IDE創建新實體。
2. 關閉集群某一節點模擬Down機
直接Control+C關閉某一節點。
3. 新建一個服務插入5000條記錄
在IDE內新建服務用於插入5000條記錄（用於觸發快照條件），調用此服務后可看到控制台輸出如下圖所示的創建快照日志。
4. 重新啟動Down機節點
通過如下命令重啟Down機節點，可看到控制台輸出如下圖所示的恢復快照日志。
sudo ./appbox
5. 驗證Down機節點快照恢復
通過tools/dbscan工具查看快照數據是否已恢復。
tools/dbscan --db=data(數據所在目錄) --cf=TableCF --take=10000 --prefix=000020017000
dbscan的參數--prefix=十六進制字串， 可以只匹配相同前綴的KV記錄
三、本篇小結：
本篇介紹了Raft快照及日志截斷回收的流程及相應的測試，GitHub上的運行時已更新可供測試。作者開發AppBoxFuture到十月一日就整一年了，期間曾多次想放棄，好在頂着巨大的壓力總算解決了這最后一個技術難點，到此基本上原型驗證是沒有大問題了，下一步的重點是完善必要功能、穩定性及性能優化，並且考慮是開源該項目還是商業化運作。