分佈式場景SSD append 引擎的點滴思考

分佈式和單機場景對append引擎設計的不一樣要求

單機：只用考慮本地數據的格式、位置和管理
分佈式：須要考慮分佈式一致協議中 日誌落盤的格式、位置和管理

append引擎和分佈式一致性協議的潛在衝突

append引擎的需求

顧名思義， append引擎指望SSD盤能儘可能把數據一路寫下去，也就是物理數據須要順序落盤，這樣能夠減少寫放大。但爲了保證比較好的數據恢復速度，一個磁盤上一般有多個複製組，這些複製組可能同時收到用戶寫請求數據而要落盤，所以邏輯上的多個複製組的數據是雜亂無序的。

分佈式一致性協議的需求

典型的分佈式一致性協議好比Raft, 在作Log compaction的時候，把以前的全部作過snapshot(索引信息落盤的）log 刪調。哪些日誌能夠刪掉呢？能夠根據log index 記錄。 哪裏的日誌能夠刪掉呢? 這就須要記錄好不一樣複製組內不一樣日誌在同一個磁盤上的位置。爲了防止掉電這些數據還在，這些信息須要持久化。同時爲了不反覆從磁盤讀入，這些信息就須要在內存中緩存一份。