redis中持久化機制有兩種方法，分別是AOF(Append Only File)與RDB.
一、RDB 將內存中的快照保存到文件。
1. RDB觸發條件分為自動觸發與手動觸發。
- 自動觸發：觸發條件可以通過redis.conf 配置文件中的 SNAPSHOTTING 下配置：
默認配置如下：
save 900 1：表示900 秒內如果至少有 1 個 key 的值變化，則保存
save 300 10：表示300 秒內如果至少有 10 個 key 的值變化，則保存
save 60 10000：表示60 秒內如果至少有 10000 個 key 的值變化，則保存
- 手動觸發：save：阻塞命令，客戶端無法進行命令操作 。bgsave：（非阻塞，子進程執行保存操作）
2. 恢復數據：
將備份文件 (dump.rdb) 移動到 redis 安裝目錄並啟動服務即可，redis就會自動加載文件數據至內存了。Redis 服務器在載入 RDB 文件期間，會一直處於阻塞狀態，直到載入工作完成為止。
3. RDB優勢與劣勢
優勢：
- RDB是一個非常緊湊(compact)的文件，它保存了redis 在某個時間點上的數據集。這種文件非常適合用於進行備份和災難恢復。
- 生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作。
- RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
劣勢：
- RDB無法做到實時持久化/秒級持久化。因為bgsave每次運行都要執行fork操作創建子進程，屬於重量級操作(內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮)，頻繁執行成本過高(影響性能)
- 存在版本兼容問題：RDB文件使用特定二進制格式保存，Redis版本演進過程中有多個格式的RDB版本，存在老版本Redis服務無法兼容新版RDB格式的問題(版本不兼容)
- 對應1，數據丟失風險. 在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改(數據有丟失)
二、AOF 命令追加到文件。
1. 開啟aof
將 redis.conf 的 appendonly 配置改為 yes 即可。
AOF 保存文件的位置和 RDB 保存文件的位置一樣，都是通過 redis.conf 配置文件的 dir 配置：
2. aof持久化策略。
在配置文件中，aof提供了三種持久化策略。可以通過對appendfsync字段配置：aof持久化策略的配置；
- no:表示不執行fsync，由操作系統保證數據同步到磁盤，速度最快，但是不太安全；
- always:表示每次寫入都執行fsync，以保證數據同步到磁盤，效率很低；
- everysec:表示每秒執行一次fsync，可能會導致丟失這1s數據。通常選擇 everysec ，兼顧安全性和效率。
3.aof文件恢復
重啟 Redis 之后就會進行 AOF 文件的載入。
異常修復命令：redis-check-aof --fix 進行修復
4.aof文件重寫
aof文件重寫觸發條件是通過配置文件的配置或者手工觸發重寫兩種方式。
配置參數：
auto-aof-rewrite-percentage：默認值為100
auto-aof-rewrite-min-size：默認值為64mb
默認Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大於64M時觸發。
注：AOF 文件重寫並不是對原文件進行重新整理，而是直接讀取服務器現有的鍵值對，然后用一條命令去代替之前記錄這個鍵值對的多條命令，生成一個新的文件后去替換原來的 AOF 文件。
no-appendfsync-on-rewrite:設置為yes表示rewrite期間對新寫操作不fsync,暫時存在內存中,等rewrite完成后再寫入，默認為no，建議yes。Linux的默認fsync策略是30秒。可能丟失30秒數據。默認值為no。
redis aof重寫是通過fork子進程的方式，子進程在進行aof重寫期間父進程是可以處理客戶端的命令操作，為了解決子進程重寫期間，客戶端向服務器執行了新的命令請求導致子進程與父進程的狀態不一致的問題，redis增加了aof重寫緩沖區，即在aof forkzi進程期間，服務器在寫客戶端命令期間也會向重寫緩沖區寫命令，待子進程完成aof重寫，通知父進程，父進程阻塞客戶端命令，將重寫緩沖區中的內容寫入到aof文件。