共計 1787 個字符，預計需要花費 5 分鐘才能閱讀完成。
這篇文章主要介紹“redis 的持久化方式怎么使用”，在日常操作中，相信很多人在 redis 的持久化方式怎么使用問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”redis 的持久化方式怎么使用”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！
redis 支持兩種持久化的方式，可以單獨使用或者結合起來使用
一、RDB
rdb 方式的持久化是通過快照完成的，當符合一定條件時 redis 會自動將內存中的所有數據執行快照操作并存儲到硬盤上。默認存儲在 redis 根目錄的 dump.rdb 文件中。(文件名在配置文件中 dbfilename)
redis 進行快照的時機（在配置文件 redis.conf 中）
save 900 1：表示 900 秒內至少一個鍵被更改則進行快照。
save 300 10
save 60 10000
redis 自動實現快照的過程
1：redis 使用 fork 函數復制一份當前進程的副本 (子進程)
2：父進程繼續接收并處理客戶端發來的命令，而子進程開始將內存中的數據寫入硬盤中的臨時文件
3：當子進程寫入完所有數據后會用該臨時文件替換舊的 RDB 文件，至此，一次快照操作完成。
注意：redis 在進行快照的過程中不會修改 RDB 文件，只有快照結束后才會將舊的文件替換成新的，也就是說任何時候 RDB 文件都是完整的。
這就使得我們可以通過定時備份 RDB 文件來實現 redis 數據庫的備份，
RDB 文件是經過壓縮的二進制文件，占用的空間會小于內存中的數據，更加利于傳輸。
手動執行 save 或者 bgsave 命令讓 redis 執行快照。
兩個命令的區別在于，save 是由主進程進行快照操作，會阻塞其它請求。bgsave 是由 redis 執行 fork 函數復制出一個子進程來進行快照操作。
文件修復：redis-check-dump
rdb 的優缺點
優點：由于存儲的有數據快照文件，恢復數據很方便。
缺點：會丟失最后一次快照以后更改的所有數據。
二、AOF
aof 方式的持久化是通過日志文件的方式。默認情況下 redis 沒有開啟 aof，可以通過參數 appendonly 參數開啟。
appendonly yes
aof 文件的保存位置和 rdb 文件的位置相同，都是 dir 參數設置的，默認的文件名是 appendonly.aof，可以通過 appendfilename 參數修改
appendfilename appendonly.aof
redis 寫命令同步的時機
a
ppendfsync always 每次都會執行
appendfsync everysec 默認 每秒執行一次同步操作（推薦，默認）
appendfsync no 不主動進行同步，由操作系統來做，30 秒一次
aof 日志文件重寫
auto-aof-rewrite-percentage 100(當目前 aof 文件大小超過上一次重寫時的 aof 文件大小的百分之多少時會再次進行重寫，如果之前沒有重寫，則以啟動時的 aof 文件大小為依據)
auto-aof-rewrite-min-size 64mb
手動執行 bgrewriteaof 進行重寫
重寫的過程只和內存中的數據有關，和之前的 aof 文件無關。
所謂的“重寫”其實是一個有歧義的詞語，實際上，AOF 重寫并不需要對原有的 AOF 文件進行任何寫入和讀取，它針對的是數據庫中鍵的當前值。
文件修復：redis-check-aof
動態切換 redis 持久方式，從 RDB 切換到 AOF（支持 Redis 2.2 及以上）
CONFIG SET appendonly yes
CONFIG SET save（可選）
注意：當 redis 啟動時，如果 rdb 持久化和 aof 持久化都打開了，那么程序會優先使用 aof 方式來恢復數據集，因為 aof 方式所保存的數據通常是最完整的。如果 aof 文件丟失了，則啟動之后數據庫內容為空。
注意：如果想把正在運行的 redis 數據庫，從 RDB 切換到 AOF，建議先使用動態切換方式，再修改配置文件，重啟數據庫。(不能直接修改配置文件，重啟數據庫，否則數據庫中數據就為空了。)
到此，關于“redis 的持久化方式怎么使用”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！
