1. RDB

1.1 RDB簡介

RDB：在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存里。

工作機制：每隔一段時間，就把內存中的數據保存到硬盤上的指定文件中。

RDB是默認開啟的！

Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

RDB的缺點是最后一次持久化后的數據可能丟失。

1.2 RDB保存策略

save 900 1    900 秒內如果至少有 1 個 key 的值變化，則保存

save 300 10   300 秒內如果至少有 10 個 key 的值變化，則保存

save 60 10000  60 秒內如果至少有 10000 個 key 的值變化，則保存

save “”  就是禁用RDB模式；

1.3 RDB常用屬性配置

1.4 RDB數據丟失的情況

兩次保存的時間間隔內，服務器宕機，或者發生斷電問題。

1.5 RDB的觸發

         ①基于自動保存的策略

         ②執行save，或者bgsave命令！執行時，是阻塞狀態。

         ③執行flushdb命令，也會產生dump.rdb，但里面是空的，沒有意義。

         ④當執行shutdown命令時，也會主動地備份數據

2. AOF

2.1 AOF簡介

1. AOF是以日志的形式來記錄每個寫操作，將每一次對數據進行修改，都把新建、修改數據的命令保存到指定文件中。Redis重新啟動時讀取這個文件，重新執行新建、修改數據的命令恢復數據。
2. 默認不開啟，需要手動開啟
3. AOF文件的保存路徑，同RDB的路徑一致。
4. AOF在保存命令的時候，只會保存對數據有修改的命令，也就是寫操作！
5. 當RDB和AOF存的不一致的情況下，按照AOF來恢復。因為AOF是對RDB的補充。備份周期更短，也就更可靠。

2.2 AOF保存策略

appendfsync always：每次產生一條新的修改數據的命令都執行保存操作；效率低，但是安全！

appendfsync everysec：每秒執行一次保存操作。如果在未保存當前秒內操作時發生了斷電，仍然會導致一部分數據丟失（即1秒鐘的數據）。

appendfsync no：從不保存，將數據交給操作系統來處理。更快，也更不安全的選擇。

推薦（并且也是默認）的措施為每秒 fsync 一次， 這種 fsync 策略可以兼顧速度和安全性。

2.3 AOF常用屬性

2.4 AOF文件的修復

如果AOF文件中出現了殘余命令，會導致服務器無法重啟。此時需要借助redis-check-aof工具來修復！

命令：redis-check-aof  --fix 文件

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對武林網的支持。如果你想了解更多相關內容請查看下面相關鏈接