5分鐘徹底理解Redis持久化
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檔案
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專案原始碼。
