redis持久化的介紹
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簡介
- AOF是以日誌的形式來記錄每個寫操作，將每一次對資料進行修改，都把新建、修改資料的命令儲存到指定檔案中。Redis重新啟動時讀取這個檔案，重新執行新建、修改資料的命令恢復資料。
- 預設不開啟，需要手動開啟
- AOF檔案的儲存路徑，同RDB的路徑一致。
- AOF在儲存命令的時候，只會儲存對資料有修改的命令，也就是寫操作！
- 當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 檔案
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對我們的支援。如果你想了解更多相關內容請檢視下面相關連結