理解和掌握Redis的持久機制，對於Redis的日常開發和運維都有很大幫助，也是在大廠面試經常被問到的知識點。 ...
為什麼需要持久化？
Redis對數據的操作都是基於記憶體的，當遇到了進程退出、伺服器宕機等意外情況，如果沒有持久化機制，那麼Redis中的數據將會丟失無法恢復。有了持久化機制，Redis在下次重啟時可以利用之前持久化的文件進行數據恢復。理解和掌握Redis的持久機制，對於Redis的日常開發和運維都有很大幫助，也是在大廠面試經常被問到的知識點。Redis支持的兩種持久化機制：
- RDB：把當前數據生成快照保存在硬碟上。
- AOF：記錄每次對數據的操作到硬碟上。
接下來，我們詳細瞭解一下這兩種持久化機制。
歡迎關註微信公眾號：萬貓學社，每周一分享Java技術乾貨。
RDB持久化
RDB（Redis DataBase）持久化是把當前Redis中全部數據生成快照保存在硬碟上。RDB持久化可以手動觸發，也可以自動觸發。
手動觸發
save和bgsave命令都可以手動觸發RDB持久化。
save命令
執行save命令會手動觸發RDB持久化，但是save命令會阻塞Redis服務，直到RDB持久化完成。當Redis服務儲存大量數據時，會造成較長時間的阻塞，不建議使用。
> save
OK
執行後，Redis的日誌中記錄：
* DB saved on disk
bgsave命令
執行bgsave命令也會手動觸發RDB持久化，和save命令不同是：Redis服務一般不會阻塞。Redis進程會執行fork操作創建子進程，RDB持久化由子進程負責，不會阻塞Redis服務進程。Redis服務的阻塞只發生在fork階段，一般情況時間很短。
> bgsave
Background saving started
執行後，Redis的日誌中記錄：
* Background saving started by pid 2645
* DB saved on disk
* RDB: 0 MB of memory used by copy-on-write
* Background saving terminated with success
bgsave命令的具體流程如下圖：
- 執行
bgsave命令，Redis進程先判斷當前是否存在正在執行的RDB或AOF子線程，如果存在就是直接結束。 - Redis進程執行fork操作創建子線程，在fork操作的過程中Redis進程會被阻塞。
- Redis進程fork完成後，
bgsave命令就結束了，自此Redis進程不會被阻塞，可以響應其他命令。 - 子進程根據Redis進程的記憶體生成快照文件，並替換原有的RDB文件。
- 子進程通過信號量通知Redis進程已完成。
歡迎關註微信公眾號：萬貓學社，每周一分享Java技術乾貨。
自動觸發
除了執行以上命令手動觸發以外，Redis內部可以自動觸發RDB持久化。自動觸發的RDB持久化都是採用bgsave的方式，減少Redis進程的阻塞。那麼，在什麼場景下會自動觸發呢？
- 在配置文件中設置了save的相關配置，如
sava m n，它表示在m秒內數據被修改過n次時，自動觸發bgsave操作。 - 當從節點做全量複製時，主節點會自動執行
bgsave操作，並且把生成的RDB文件發送給從節點。 - 執行
debug reload命令時，也會自動觸發bgsave操作。 - 執行
shutdown命令時，如果沒有開啟AOF持久化也會自動觸發bgsave操作。
RDB優點
RDB文件是一個緊湊的二進位壓縮文件，是Redis在某個時間點的全部數據快照。所以使用RDB恢複數據的速度遠遠比AOF的快，非常適合備份、全量複製、災難恢復等場景。
RDB缺點
每次進行bgsave操作都要執行fork操作創建子經常，屬於重量級操作，頻繁執行成本過高，所以無法做到實時持久化，或者秒級持久化。
另外，由於Redis版本的不斷迭代，存在不同格式的RDB版本，有可能出現低版本的RDB格式無法相容高版本RDB文件的問題。
歡迎關註微信公眾號：萬貓學社，每周一分享Java技術乾貨。
AOF持久化
AOF（Append Only File）持久化是把每次寫命令追加寫入日誌中，當需要恢複數據時重新執行AOF文件中的命令就可以了。AOF解決了數據持久化的實時性，也是目前主流的Redis持久化方式。
AOF持久化流程
AOF流程如下圖：
- 命令追加（append）：所有寫命令都會被追加到AOF緩存區（aof_buf）中。
- 文件同步（sync）：根據不同策略將AOF緩存區同步到AOF文件中。
- 文件重寫（rewrite）：定期對AOF文件進行重寫，以達到壓縮的目的。
- 數據載入（load）：當需要恢複數據時，重新執行AOF文件中的命令。
文件同步策略
AOF持久化流程中的文件同步有以下幾個策略：
- always：每次寫入緩存區都要同步到AOF文件中，硬碟的操作比較慢，限制了Redis高併發，不建議配置。
- no：每次寫入緩存區後不進行同步，同步到AOF文件的操作由操作系統負責，每次同步AOF文件的周期不可控，而且增大了每次同步的硬碟的數據量。
- eversec：每次寫入緩存區後，由專門的線程每秒鐘同步一次，做到了兼顧性能和數據安全。是建議的同步策略，也是預設的策略。
觸發文件重寫
AOF持久化流程中的文件重寫可以手動觸發，也可以自動觸發。
- 手動觸發：使用
bgrewriteaof命令。 - 自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置確定自動觸發的時機。auto-aof-rewrite-min-size表示運行AOF重寫時文件大小的最小值，預設為64MB；auto-aof-rewrite-percentage表示當前AOF文件大小和上一次重寫後AOF文件大小的比值的最小值，預設為100。只用前兩者同時超過時才會自動觸發文件重寫。
歡迎關註微信公眾號：萬貓學社，每周一分享Java技術乾貨。
AOF持久化配置
對AOF持久化的具體流程有了瞭解後，我們來看一下如何配置AOF。AOF持久化預設是不開啟的，需要修改配置文件，如：
# appendonly改為yes，開啟AOF
appendonly yes
# AOF文件的名字
appendfilename "appendonly.aof"
# AOF文件的寫入方式
# everysec 每個一秒將緩存區內容寫入文件 預設開啟的寫入方式
appendfsync everysec
# 運行AOF重寫時AOF文件大小的增長率的最小值
auto-aof-rewrite-percentage 100
# 運行AOF重寫時文件大小的最小值
auto-aof-rewrite-min-size 64mb
微信公眾號：萬貓學社
微信掃描二維碼
獲得更多Java技術乾貨
