Redis提供了將數據按期自動持久化到硬盤的能力,包括RDB,AOF兩種方案,兩種方案各有利弊,能夠配合起來同時使用,確保數據的穩定性。redis
Redis數據持久化機制是能夠關閉的。若是把 Redis服務做爲緩存服務使用,Redis中存儲的全部數據都不是該數據的主體而僅僅是同步過來的備份,則能夠關閉Redis的數據持久化機制。緩存
但一般,仍要建議至少開啓 RDB方式的數據持久化,由於:安全
RDB方式的持久化幾乎不損耗 Redis自己的性能,在進行 RDB持久化時,Redis 主進程惟一須要作的事情就是 fork出一個子進程,全部持久化工做都由子進程完成。bash
Redis不管由於什麼緣由crash掉以後,重啓時可以自動恢復到上一次RDB快照中記錄的數據。這省去了手工從其餘數據源(如DB)同步數據的過程,並且要比其餘任何的數據恢復方式都要快。app
如今硬盤那麼大,真的不缺那一點地方ide
採用RDB持久方式,Redis會按期保存數據快照至一個 rbd 文件中,並在啓動時自動加載rdb文件,恢復以前保存的數據。能夠在配置文件中配置 Redis 進行快照保存的時機:工具
save [seconds] [changes]
意爲在[seconds]秒內若是發生了[changes]次數據修改,則進行一次RDB快照保存,例如性能
save 60 100
會讓Redis每60秒檢查一次數據變動狀況,若是發生了100次或以上的數據變動,則進行RDB快照保存。
能夠配置多條save指令,讓Redis執行多級的快照保存策略。
Redis默認開啓RDB快照,默認的RDB策略以下:線程
save 900 1 save 300 10 save 60 10000
也能夠經過BGSAVE命令手工觸發RDB快照保存。日誌
對性能影響最小。如前文所述,Redis在保存RDB快照時會fork出子進程進行,幾乎不影響Redis處理客戶端請求的效率。
每次快照會生成一個完整的數據快照文件,因此能夠輔以其餘手段保存多個時間點的快照(例如把天天0點的快照備份至其餘存儲媒介中),做爲很是可靠的災難恢復手段。
使用RDB文件進行數據恢復比使用AOF要快不少。
快照是按期生成的,因此在Redis crash時或多或少會丟失一部分數據。
若是數據集很是大且CPU不夠強(好比單核CPU),Redis在fork子進程時可能會消耗相對較長的時間(長至1秒),影響這期間的客戶端請求。
採用AOF持久方式時,Redis會把每個寫請求都記錄在一個日誌文件裏。在Redis重啓時,會把AOF文件中記錄的全部寫操做順序執行一遍,確保數據恢復到最新。
AOF默認是關閉的,如要開啓,進行以下配置:
appendonly yes
AOF提供了三種fsync配置,always/everysec/no,經過配置項[appendfsync]指定:
appendfsync no:不進行fsync,將flush文件的時機交給OS決定,速度最快
appendfsync always:每寫入一條日誌就進行一次fsync操做,數據安全性最高,但速度最慢
appendfsync everysec:折中的作法,交由後臺線程每秒fsync一次
隨着AOF不斷地記錄寫操做日誌,一定會出現一些無用的日誌,例如某個時間點執行了命令SET key1 "abc",在以後某個時間點又執行了SET key1 "bcd",那麼第一條命令很顯然是沒有用的。大量的無用日誌會讓AOF文件過大,也會讓數據恢復的時間過長。
因此Redis提供了AOF rewrite功能,能夠重寫AOF文件,只保留可以把數據恢復到最新狀態的最小寫操做集。
AOF rewrite能夠經過BGREWRITEAOF命令觸發,也能夠配置Redis按期自動進行:
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
上面兩行配置的含義是,Redis在每次AOF rewrite時,會記錄完成rewrite後的AOF日誌大小,當AOF日誌大小在該基礎上增加了100%後,自動進行AOF rewrite。同時若是增加的大小沒有達到64mb,則不會進行rewrite。
最安全,在啓用appendfsync always時,任何已寫入的數據都不會丟失,使用在啓用appendfsync everysec也至多隻會丟失1秒的數據。
AOF文件在發生斷電等問題時也不會損壞,即便出現了某條日誌只寫入了一半的狀況,也可使用redis-check-aof工具輕鬆修復。
AOF文件易讀,可修改,在進行了某些錯誤的數據清除操做後,只要AOF文件沒有rewrite,就能夠把AOF文件備份出來,把錯誤的命令刪除,而後恢復數據。
AOF文件一般比RDB文件更大
性能消耗比RDB高
數據恢復速度比RDB慢