Redis 2種持久化方式（ RDB、 AOF ）配置

看了一些redis相關的博文和文檔，對redis的持久化只停留在原理及理論層面，直接點 要怎麼配置。

Redis有2種持久化的方式對比：
一種是Snapshot(RDB)，就是保存某一時刻的數據在磁盤；
另外一種是append-only file(AOF)，就是以追加的方式記錄所有寫操作的命令到磁盤文件裏面。

1、Snapshot
1.1 在redis.conf裏面，配置的參數主要包括以下部分：
save <seconds> <changes>
stop-writes-on-bgsave-error yes
rdbcompression yes
dbfilename dump.rdb
dir ./

save <seconds> <changes>：在X秒內如果key有至少X次改變就觸發持久化，例如save 900 1的話就是在900秒如果key有至少1次改變就觸發持久化。如果想關閉此功能的話，可以把全部save行都註釋或刪除或者使用save ""。
如：
save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error：在bgsave遇到error的時候是否停止持久化，默認是yes代表是，no代表不是
rdbcompression：是否壓縮，默認是yes代表是，no代表不是，如果想節省CPU的話就設爲no，但是rdb文件會比較大
dbfilename：持久化的文件名字，默認是dump.rdb
dir：持久化的目錄名字，默認是redis.conf所在的目錄./

1.2 redis有5種觸發snapshot持久化的方式
1）客戶端執行BGSAVE命令初始化一個會佔用一定內存的background進程
2）客戶端執行SAVE命令，這個時候redis會阻塞所有命令直到snapshot保存完畢，一般很少使用，除非你可以接受redis暫時阻塞或者沒有足夠內存執行BGSAVE
3）redis.conf文件配置了save <seconds> <changes>，當滿足條件的時候自動觸發BGSAVE操作
4）服務器接收到SHUTDOWN命令或者TERM signal會執行SAVE，redis會阻塞所有命令直到snapshot保存完畢，然後關閉redis
5）1臺redis連接到另外1臺redis並且執行SYNC命令，由於某種原因如果SYNC沒有執行，主redis會先執行BGSAVE
1.3 需要注意的是如果服務器crash的話會導致自從上次snapshot完成之後的數據丟失

2，Append-only file（AOF）
2.1 在redis.conf裏面，配置的參數主要包括以下部分：
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
dir ./

appendonly：是否啓動aof，默認是no代表不啓用，yes代表啓用
啓動、修復、恢復
①正常恢復
啓動：設置yes,修改默認的appendonly no,改爲yes
將有數據的aof文件複製一份保存到對應目錄(config get dir)
恢復：重啓redis然後重新加載
②異常恢復
啓動：設置yes,修改默認的appendonly no,該爲yes
備份被寫壞的AOF文件
修復：redis-check-aof  --fix 進行修復
恢復：重啓redis然後重新加載

appendfilename：aof的文件名，默認是appendonly.aof
appendfsync：觸發的間隔，默認是everysec代表每秒，另外還有always代表有改變都觸發，性能最差但數據最安全，no代表讓OS自己決定什麼時候執行，性能最好但數據不安全

dir：和上述是同一個參數（共用），持久化的目錄名字，默認是redis.conf所在的目錄./
2.2 需要注意的是如果你使用了SSD的話，appendfsync設置always會可能導致write amplification從而很大影響SSD的壽命；另外就是aof一般是比rdb文件較大，恢復時間較長，因爲要重新執行所有的寫操作

3，Rewriting/compacting AOF
3.1 因爲AOF會以追加的方式記錄所有寫操作的命令到磁盤文件裏面，所以文件會越來越大，導致redis重啓的時候恢復時間較長。爲了緩解這種問題，redis使用了BGREWRITEAOF，用於刪除重複多餘的寫命令，類似BGSAVE，是一個佔用一定系統資源的background進程。因爲rewrite的時候會刪除舊的AOF文件，如果AOF文件比較大的話，會消耗更多的系統資源

3.2 在redis.conf裏面，配置的參數主要包括以下部分：
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

no-appendfsync-on-rewrite：在aof rewrite的時候上述appendfsync是否暫時停止，默認是no代表不停止，yes代表停止，不會造成I/O資源競爭，性能較前者好
auto-aof-rewrite-percentage：自動觸發aof rewrite的百分比，默認是100%，就是比上次rewrite的1倍
auto-aof-rewrite-min-size：自動觸發aof rewrite的最小size，默認是64mb，就是如果size超過64mb，而且是上次執行的1倍，就會自動觸發

4，Snapshot和AOF的對比
- snapshot在下一次觸發前如果服務器crash了，在上次snapshot之後修改的數據會丟失，而AOF是記錄所有的寫操作，在數據完整性來說，AOF比snapshot要好
- snapshot持久化的文件rdb一般比aof要小，所以在恢復的時候snapshot會快一點，而且節省硬件資源
- 如果服務器在寫aof的時候故障導致aof文件損壞，可以使用自帶的工具redis-check-aof --fix修復，而snapshot文件rdb損壞是無法修復的

所以如果你可以容忍數據丟失的話，可以使用snapshot方式，而且也是比AOF要節省資源，否則的話就使用AOF方式，或者同時使用2種方式（重啓的時候會優先使用AOF）。