(Redis設計與實現-4) 持久化

一.RDB

RDB(Redis DataBase)，也常叫作snapshots：是在某個時間點將數據寫入一個臨時文件，持久化結束後，用這個臨時文件替換上次持久化的文件，達到數據恢復。 snapshot首先將數據寫入臨時文件，當成功結束後，將臨時文件重名爲dump.rdb。

//使用配置文件進行持久化
save 900 1 #900秒內若是超過1個key被修改，則發起快照保存
save 300 10 #300秒內若是超過10個key被修改，則發起快照保存


//使用命令進行持久化
redis-cli -h ip -p port save #用主線程進行持久化，這種方式會阻塞全部client請求
redis-cli -h ip -p port bgsave #另外開啓一條子線程進行持久化

二.AOF

AOF(Append-only file):將「操做 + 數據」以格式化指令的方式追加到操做日誌文件的尾部，在append操做返回後(已經寫入到文件或者即將寫入)，才進行實際的數據變動，「日誌文件」保存了歷史全部的操做過程；當server須要數據恢復時，能夠直接replay此日誌文件，便可還原全部的操做過程。

(1).同步寫入

AOF是文件操做，對於變動操做比較密集的server，那麼必將形成磁盤IO的負荷加劇；此外redis提供了3中aof記錄同步選項（appendfsync）：

always：每一條aof記錄都當即同步到文件，這是最安全的方式，也覺得更多的磁盤操做和阻塞延遲，是IO開支較大。
everysec：每秒同步一次，性能和安全都比較中庸的方式，也是redis推薦的方式。若是遇到物理服務器故障，有可能
致使最近一秒內aof記錄丟失(可能爲部分丟失)。
no：redis並不直接調用文件同步，而是交給操做系統來處理，操做系統能夠根據buffer填充狀況/通道空閒時間等擇機
觸發同步；這是一種普通的文件操做方式。性能較好，在物理服務器故障時，數據丟失量會因OS配置有關。

(2).壓縮AOF日誌文件

AOF文件會不斷增大，它的大小直接影響「故障恢復」的時間,並且AOF文件中歷史操做是能夠丟棄的。AOF rewrite操做就是「壓縮」AOF文件的過程，固然redis並無採用「基於原aof文件」來重寫的方式，而是採起了相似snapshot的方式：基於copy-on-write，全量遍歷內存中數據，而後逐個序列到aof文件中。

//使用配置文件進行持久化
no-appendfsync-on-rewrite no  #在aof-rewrite期間，appendfsync是否暫緩文件同步
auto-aof-rewrite-min-size 64mb  #aof文件rewrite觸發的最小文件尺寸(mb,gb)
auto-aof-rewrite-percentage 100  #相對於「上一次」rewrite，本次rewrite觸發時aof文件應該增加的百分比。 


//使用命令進行持久化
redis-cli -h ip -p port bgrewriteaof #開啓一個子進程來完成rewrite