redis - 持久化

咱們知道redis很快是由於都是純內存操做的，那若是數據僅僅在內存中，redis宕機了數據是否是就沒了，此時大量的請求在redis中找不到緩存的數據，就會直接請求數據庫，致使數據庫掛掉。因此redis提供了RDB和AOF兩種不一樣的持久化方法把數據存儲到硬盤中。 RDB是以快照的形式，將某一時刻的數據都寫入到硬盤。AOF(append-only file)是將每條執行的命令保存在硬盤，恢復的時候，能夠從文件裏讀取命令在redis裏從新執行，達到恢復的效果。這兩種方式能夠單獨使用，也能夠一塊兒使用，取決於咱們的實際應用場景需求。

RDB

在RDB中持久化的觸發有兩種：自動觸發和手動觸發。

手動觸發

手動觸發有save和bgsave命令。
當redis接收到save命令時，就會建立快照，而且在快照建立完畢以前，不會響應其餘的命令。
當redis接收到bgsave命令時，redos會fork一個子進程來建立快照，而後父進程會繼續處理其餘的命令。雖然不會阻塞其餘命令，可是建立子進程會致使redis停頓，而且因爲子進程會爭搶資源，致使建立快照的速度會比save慢。

自動觸發

save配置以下：表明在N秒內，若是有了M次的變化，則觸發bgsave命令，若是配置了多個，則任意一個生效都觸發bgsave命令。

save <seconds> <changes>

redis默認的配置以下：

#900秒內有1次變化則建立快照
save 900 1
#300秒內有10次變化則建立快照
save 300 10
#60秒內有10000次變化則建立快照
save 60 10000

除了上面的規則被觸發會執行bgsave外，redis接收到shutdown命令或者服務器關閉請求，又或者收到標準TERM信號時，會執行save命令，此時客戶端的全部的請求將被阻塞，不在執行，而且在save命令執行完後關閉服務器。
redis的其餘關於RDB配置

# bgsava失敗後是否中止接收數據
stop-writes-on-bgsave-error yes
# 是否對快照進行壓縮
rdbcompression yes
# 快照文件名
dbfilename dump.rdb

優缺點

優勢：

1. 因爲是快照形式，因此適用於全量備份。
2. 恢復速度快與AOF。

缺點：

1. 沒法實時建立快照，有可能形成部分數據丟失。
2. 經過子進程建立快照時，若是數據文件太大，有可能致使redis短暫中止服務。

AOF

AOF會將redis執行過的命令追加到文件的末尾，也就是說若是從文件的開頭開始執行到最後，就會獲得以前同樣的數據。redis默認是沒有開啓AOF的，須要appendonly設置爲yes纔開啓。
除了appendonly配置，還有其餘配置：

# 默認AOF文件名
appendfilename "appendonly.aof"
# 每一個命令都要追加到文件，性能相對差
# appendfsync always
# 每秒同步，最多會丟失一秒的數據
appendfsync everysec
# 讓操做系統決定什麼時候同步，不可控，不推薦
# appendfsync no

因爲AOF須要一直的寫文件，會致使文件會一直增加，redis提供了AOF文件壓縮的命令，BGREWRITEAOF。相似於bgsave，BGREWRITEAOF也會fork一個子進程，對AOF文件進行重寫，因此同樣會有由於建立子進行致使的資源爭搶和內存佔用的問題。對於重寫，有如下配置：

# 比上一次重寫後的體積大於100%而且大於64m的時候重寫
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

優缺點

優勢：

1. 最多丟失一秒的數據。
2. 把命令追加到文件末尾，沒有任何磁盤尋址的開銷，寫入的速度很是快。

缺點：

1. 文件大，恢復速度慢。
2. 相對於RDB，因爲每秒須要追加日誌，支持的寫QPS較低。

恢復

需恢復的時候，只要把RDB或者AOF文件放在配置的路徑下面，重啓redis服務器就能夠恢復。若是同時存在兩種持久化方式，而且有AOF文件，就會從AOF文件恢復數據，不然從RDB文件恢復數據。