目錄
-
介紹
由於redis是一個內存數據庫，所有的數據都是保存在內存當中的，內存當中的數據極易丟失，所以redis的數據持久化就顯得尤爲重要，在redis當中，提供了兩種數據持久化的方式，分別爲RDB以及AOF，且redis默認開啓的數據持久化方式爲RDB方式
-
RDB方案
Redis會定期保存數據快照至一個rbd文件中，並在啓動時自動加載rdb文件，恢復之前保存的數據。可以在配置文件中配置Redis進行快照保存的時機。
自動觸發
在redis.conf文件中修改，意爲在[seconds]秒內如果發生了[changes]次數據修改，則進行一次RDB快照保存，如下，會讓Redis每60秒檢查一次數據變更情況，如果發生了100次或以上的數據變更，則進行RDB快照保存。可以配置多條save指令，讓Redis執行多級的快照保存策略。Redis默認開啓RDB快照
save seconds changes
save 60 100
手動觸發
SAVE或者BGSAVE命令手動觸發RDB快照保存。SAVE 和 BGSAVE 兩個命令都會調用 rdbSave 函數，但它們調用的方式各有不同
SAVE：SAVE 直接調用 rdbSave ，阻塞 Redis 主進程，直到保存完成爲止。在主進程阻塞期間，服務器不能處理客戶端的任何請求。
BGSAVE：BGSAVE 則 fork 出一個子進程，子進程負責調用 rdbSave ，並在保存完成之後向主進程發送信號，通知保存已完成。 Redis 服務器在BGSAVE 執行期間仍然可以繼續處理客戶端的請求。
優點
1.對性能影響最小。如前文所述，Redis在保存RDB快照時會fork出子進程進行，幾乎不影響Redis處理客戶端請求的效率。
2.每次快照會生成一個完整的數據快照文件，所以可以輔以其他手段保存多個時間點的快照（例如把每天0點的快照備份至其他存儲媒介中），作爲非常可靠的災難恢復手段。
3.使用RDB文件進行數據恢復比使用AOF要快很多
缺點
1.快照是定期生成的，所以在Redis crash（崩潰）時或多或少會丟失一部分數據。
2.如果數據集非常大且CPU不夠強（比如單核CPU），Redis在fork子進程時可能會消耗相對較長的時間，影響Redis對外提供服務的能力。
-
AOF方案
採用AOF持久方式時，Redis會把每一個寫請求都記錄在一個日誌文件裏。在Redis重啓時，會把AOF文件中記錄的所有寫操作順序執行一遍，確保數據恢復到最新。AOF默認是關閉的，如要開啓，需要在redis.conf文件中進行如下配置
appendonly yes
AOF提供了三種fsync配置，always/everysec/no，通過redis.conf文件配置項[appendfsync]指定：
appendfsync no：不進行fsync，將flush文件的時機交給OS（操作系統）決定，速度最快
appendfsync always：每寫入一條日誌就進行一次fsync操作，數據安全性最高，但速度最慢
appendfsync everysec：折中的做法，交由後臺線程每秒fsync一次
隨着AOF不斷地記錄寫操作日誌，因爲所有的操作都會記錄，所以必定會出現一些無用的日誌。大量無用的日誌會讓AOF文件過大，也會讓數據恢復的時間過長。不過Redis提供了AOF rewrite功能，可以重寫AOF文件，只保留能夠把數據恢復到最新狀態的最小寫操作集，AOF rewrite可以通過BGREWRITEAOF命令觸發，也可以配置Redis定期自動進行，通過redis.conf文件配置：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
上面兩行配置的含義是，Redis在每次AOF rewrite時，會記錄完成rewrite後的AOF日誌大小，當AOF日誌大小在該基礎上增長了100%後，自動進行AOF rewrite。同時如果增長的大小沒有達到64mb，則不會進行rewrite。
優點
1、最安全，在啓用appendfsync always時，任何已寫入的數據都不會丟失，使用在啓用appendfsync everysec也至多隻會丟失1秒的數據
1、AOF文件在發生斷電等問題時也不會損壞，即使出現了某條日誌只寫入了一半的情況，也可以使用redis-check-aof工具輕鬆修復。
1、AOF文件易讀，可修改，在進行了某些錯誤的數據清除操作後，只要AOF文件沒有rewrite，就可以把AOF文件備份出來，把錯誤的命令刪除，然後恢復數據。
缺點
1、AOF文件通常比RDB文件更大
2、性能消耗比RDB高
3、數據恢復速度比RDB慢