Redis持久化

RDB快照

在預設情況下，Redis將記憶體資料庫快照保存到dump.rdb的二進位文件中。
可以對Redis進行設置，讓它在“N秒內數據集至少有N個改動”， 這一條件被滿足時，自動保存一次數據集。比如說：讓Redis滿足“60秒內至少有1000個鍵被改動”這一個條件時，自動保存一次數據集。

save 60 1000

除了在配置文件中使用save關鍵字設置RDB快照，還可以在命令行中手動執行命令生成RDB快照，進入redis客戶端執行命令save或bgsave可以生成dump.rdb文件。
每次執行命令都會將所有redis記憶體快照保存到一個rdb文件里，並覆蓋原有的rdb快照文件。
save是同步命令，bgsave是非同步命令，bgsave會從redis主進程fork出一個子進程專門用來生成rdb二進位文件。

AOF（append only file）

快照功能並不是非常durable，如果redis因為某些原因而造成故障停機，那麼伺服器將丟失最近寫入且未保存到快照中的那些數據。從1.1版本，redis增加了一種完全durable的方式：AOF持久化，將修改的每一條指令記錄進appendonly.aof中。修改配置文件來打開aof功能：

appendonly yes

打開aof功能，每當redis執行一個改變數據集的命令時，這個命令就會追加到aof文件的末尾。這樣的話，當redis重新啟動時，程式就會通過執行aof文件中的命令來達到重建數據集的目的。
可以配置redis多久才將命令持久化到磁碟一次。

appendfsync always：每次有新命令追加到aof文件時就執行一個持久化，非常慢但是安全
appendfsync everysec：每秒執行一次持久化，足夠快（和使用rdb持久化差不多）並且在故障時只會丟失1秒鐘的數據
appendfsync no：從不持久化，將數據交給操作系統來處理。redis處理命令速度加快但是不安全。

預設情況下 ，每秒執行一次fsync， 這種fsync策略可以兼顧安全性和速度。
rdb和aof的區別：

redis啟動時如果既有rdb文件又有aof文件則優先選擇aof文件恢複數據，因為aof文件一般來說數據更安全一點。

二、AOF重寫
aof文件里可能有太多“瑣碎”指令，所以aof會定期根據記憶體的最新數據重新生成aof文件
有兩個配置可以控制aof自動重寫的頻率：

auto-aof-rewrite-min-size 64mb： aof文件至少要達到64m才會觸發制動重寫，文件太小恢復速度本來就很快，重寫的意義不大

auto-aof-rewrite-percentage 100：aof文件上一次重寫後文件大小增長了100%則再次觸發重寫

當然aof還可以手動重寫，進入redis客戶端執行命令bgrewriteaof重寫aof。
觸發aof重寫時，redis會fork一個子進程去做，不會對redis正常命令處理有太多影響。

Redis 4.0混合持久化

重啟redis恢複數據集時，很少會使用rdb來恢復記憶體狀態，因為會丟失大量數據。通常會使用aof日誌恢複數據，但是重放aof日誌性能相對rdb來說要慢很多，這樣在redis實例很大的情況下，啟動需要花費很長時間。Redis4.0為瞭解決這個問題，帶來了新的持久化選項——混合持久化。

aof-use-rdb-preamble yes

混合持久化aof文件結構：

如果開啟了混合持久化，aof在重寫時，不再是單純將記憶體數據轉換為RESP命令寫入aof文件，而是將重寫這一刻之前的記憶體做rdb快照處理，並且將rdb快照內容和增量的aof修改記憶體數據的命令存在一起，都寫入新的aof文件，新的aof文件一開始不叫appendonly.aof，等到重寫完成後，新的aof文件才會進行改名，原子的覆蓋原有的aof文件，完成新舊兩個aof文件的替換。
於是在redis重啟的時候，可以先載入rdb文件，然後再重放增量的aof日誌就可以完全替代之前的aof全量文件重放，因此重啟效率大幅得到提高。

還沒關註我的公眾號？

• 掃文末二維碼關註公眾號【小強的進階之路】可領取如下:
• 學習資料： 1T視頻教程：涵蓋Javaweb前後端教學視頻、機器學習/人工智慧教學視頻、Linux系統教程視頻、雅思考試視頻教程；
• 100多本書：包含C/C++、Java、Python三門編程語言的經典必看圖書、LeetCode題解大全；
• 軟體工具：幾乎包括你在編程道路上的可能會用到的大部分軟體；
• 項目源碼：20個JavaWeb項目源碼。