一、redis持久化方式
Redis 提供了兩種持久化方式，一種是基於快照形式的 RDB，另一種是基於日誌形式的 AOF，每種方式都有自己的優缺點。
1.1、RDB持久化的概述
-
RDB 基於內存快照，是 Redis 默認開啓的持久化方式，並不需要我們單獨開啓。
-
RDB 有兩種持久化方式：手動觸發 和 自動觸發，手動觸發使用以下兩個命令：
-
save：會阻塞當前 Redis 服務器響應其他命令，直到 RDB 快照生成完成爲止，對於內存比較大的實例會造成長時間阻塞，所以線上環境不建議使用
-
bgsave：Redis 主進程會 fork 一個子進程，RDB 快照生成有子進程來負責，完成之後，子進程自動結束，bgsave 只會在 fork 子進程的時候短暫的阻塞，這個過程是非常短的，所以推薦使用該命令來手動觸發
-
-
大部分情況，我們會通過配置 時間間隔 觸發 RDB 文件寫入。
1.2、AOF持久化
-
Redis 默認並沒有開啓 AOF 持久化方式，需要我們自行開啓，與 RDB 不同的是 AOF 是以記錄操作命令的形式來持久化數據的，我們可以查看以下 AOF 的持久化文件 appendonly.aof
-
appendfsync 的配置項有以下三種值可選：
always：每一次系統 serverCorn 函數調用就刷新一次緩存區
everysec：每秒執行一次磁盤寫入，期間所有的命令都會存儲在 aof 緩存區
no：不做控制，任由操作系統決定什麼時候刷新緩衝區
redis 默認配置是 everysec，即每秒刷新一次緩存區。
二、redis 配置文件
2.1、RDB 持久化配置
- save格式：
save <指定時間間隔> <執行指定次數更新操作>，滿足條件就將內存中的數據同步到硬盤中。
[root@localhost ~]# vim /etc/redis/6379.conf
save 900 1
save 300 10
save 60 10000
//生成快照失敗時，主線程是否停止寫入
stop-writes-on-bgsave-error yes
//是否採用壓縮算法存儲
rdbcompression yes
//數據恢復時是否檢測 RDB文件有效性
rdbchecksum yes
//RDB快照生成的文件名稱，一般採用默認的dump.rdb
dbfilename dump.rdb
//快照生成的路徑，AOF也是存放在這個路徑下面
dir /var/lib/redis/6379
2.2、AOF持久化配置
- 開啓AOF 持久化就在 redis.conf 配置文件中將 appendonly no 調整爲 appendonly yes 。
[root@localhost ~]# vim /etc/redis/6379.conf
//開啓AOF持久化
appendonly yes
//AOF文件名稱，默認值爲 appendonly.aof
appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec 默認推薦
# appendfsync no
//忽略最後一條可能存在問題的指令
aof-load-truncated yes
2.3、AOF 重寫
-
理論上來說，隨着 redis 服務器運行時間的持續，生成的 aof 文件只會越來越大，redis 提供 AOF 重寫策略幫助優化和壓縮 aof 文件。能將幾百條甚至幾千條的命令日誌，重寫優化成個位數。帶給我們最直觀的好處就是，aof 文件體積變小，數據恢復速度變快。
-
一般來說，我們可以通過向 redis 服務器發送 bgrewriteaof 命令觸發服務器對 aof 文件進行重寫，如果當前有正在運行的重寫子進程，則本次重寫 會推遲執行，否則，直接觸發一次重寫。
-
除此之外，我們還可以在配置文件中配置 aof 文件達到多大，自動觸發文件重寫。
vim /etc/redis/6379.conf
//設置爲yes表示rewrite操作不進行同步fsync,暫時存在內存中,避免造成磁盤IO操作衝突，默認爲no，建議yes。
no-appendfsync-on-rewrite no
//當前aof文件大小超過上一次重寫的aof文件大小的百分之多少時進行重寫新的日誌進程
auto-aof-rewrite-percentage 100
//允許重寫aof文件的最小值，避免剛開始啓動Reids時由於文件尺寸較小導致頻繁的重寫操作
auto-aof-rewrite-min-size 64mb
三、RDB與AOF的持久化對比
3.1、RDB 優缺點
RDB 文件中保存的是 redis 內存中所有的數據一份快照。
- 優點：
1、相同的數據量下，rdb 文件要小於 aof 文件，且恢復速度要快於 aof
2、rdb 文件中是整個數據的完整備份快照，數據存儲緊湊即便不同版本的 redis，也能順利恢復
3、整個 rdb 持久化，只需要 fork 一個子進程進行持久化即可，父進程依然可以提供服務，效率最大化。 - 缺點：
1、容易丟失數據，即便配置了事件時間觸發備份，也至少丟失一秒數據
2、如果數據量太大，fork 子進程的時候會阻塞毫秒級別時間
3.1、AOF 優缺點
AOF 是基於命令操作日誌，每條更新命令都會被刷到緩存區，然後在特定的時間節點被寫入 aof 磁盤文件。
- 優點：
1、相較於 RDB，AOF 數據可靠性更強，最多丟失一秒數據
2、數據庫容錯率變好，一些誤操作可以通過直接改 aof 文件進行回退 - 缺點：
1、AOF 文件通常較大且恢復效率比不上 RDB，不適合做數據冷備份
總的來說，AOF 策略會使數據穩定性更高，具有更完整的數據備份，RDB 恢復效率高適合做災難恢復，建議生產環境上兩者都開啓。