- RDB：快照形式是直接把內存中的數據保存到一個 dump 文件中，恢復時是將快照文件直接讀到內存裏。
- AOF：把全部的對Redis的服務器進行修改的命令都存到一個文件裏，命令的集合。
Redis默認是快照RDB的持久化方式java
RDB
RDB 有兩種觸發方式，分別是自動觸發和手動觸發redis
-
自動觸發緩存
在 redis.conf 配置文件中的 SNAPSHOTTING 下，加上以下配置：安全
save 900 1：表示900 秒內若是至少有 1 個 key 的值變化，則保存 save 300 10：表示300 秒內若是至少有 10 個 key 的值變化，則保存 save 60 10000：表示60 秒內若是至少有 10000 個 key 的值變化，則保存
固然若是你只是用Redis的緩存功能，不須要持久化，那麼你能夠註釋掉全部的 save 行來停用保存功能，也可使用`redis-cli config set save ""命令服務器
-
手動觸發app
手動觸發Redis進行RDB持久化的命令有兩種：異步
-
save函數
該命令會阻塞當前Redis服務器，執行save命令期間，Redis不能處理其餘命令，直到RDB過程完成爲止工具
-
bgsave性能
執行該命令時，Redis會在後臺異步進行快照操做，快照同時還能夠響應客戶端請求。具體操做是Redis進程執行fork操做建立子進程，RDB持久化過程由子進程負責，完成後自動結束。阻塞只發生在fork階段，通常時間很短
-
基本上 Redis 內部全部的RDB操做都是採用 bgsave 命令
恢復數據
將備份文件 (dump.rdb) 移動到 redis 安裝目錄並啓動服務便可，redis就會自動加載文件數據至內存了。Redis 服務器在載入 RDB 文件期間，會一直處於阻塞狀態，直到載入工做完成爲止。
獲取 redis 的安裝目錄可使用 config get dir 命令
RDB優點與劣勢
優點：
- RDB是一個很是緊湊(compact)的文件，它保存了redis 在某個時間點上的數據集。這種文件很是適合用於進行備份和災難恢復
- 生成RDB文件的時候，redis主進程會fork()一個子進程來處理全部保存工做，主進程不須要進行任何磁盤IO操做
- RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快
劣勢：
- RDB方式數據沒辦法作到實時持久化/秒級持久化。由於bgsave每次運行都要執行fork操做建立子進程，屬於重量級操做(內存中的數據被克隆了一份，大體2倍的膨脹性須要考慮)，頻繁執行成本太高(影響性能)
- RDB文件使用特定二進制格式保存，Redis版本演進過程當中有多個格式的RDB版本，存在老版本Redis服務沒法兼容新版RDB格式的問題(版本不兼容)
- 在必定間隔時間作一次備份，因此若是redis意外down掉的話，就會丟失最後一次快照後的全部修改(數據有丟失)
AOF
AOF配置
在 redis.conf 配置文件的 APPEND ONLY MODE 下：
- appendonly no 默認配置，表示不開啓AOF持久化
- appendfilename 「appendonly.aof」 AOF日誌文件名
- appendfsync： aof持久化策略的配置；
- no表示不執行fsync，由操做系統保證數據同步到磁盤，速度最快，可是不太安全；
- always表示每次寫入都執行fsync，以保證數據同步到磁盤，效率很低；
- everysec表示每秒執行一次fsync，可能會致使丟失這1s數據。一般選擇 everysec ，兼顧安全性和效率
AOF文件恢復
重啓 Redis 以後就會進行 AOF 文件的載入
AOF重寫
AOF文件不斷變大，Redis爲了解決這種狀況，在文件大小達到必定閾值後，進行AOF重寫，對AOF文件進行壓縮，只保留能夠恢復數據的最小指令集
舉個例子：
sadd key "A" "B" "C"
若是不重寫會保留三條sadd指令，可是重寫只會保留一條
- 執行AOF重寫的時候，會直接讀取服務器內存的全部鍵值對，不是對以前的AOF文件進行整理
- 子進程進行 AOF 重寫期間，服務器進程（父進程）能夠繼續處理其餘命令
- 子進程帶有父進程的數據副本，使用子進程而不是線程，能夠在避免使用鎖的狀況下，保證數據的安全性
主進程和子進程以前可能會產生數據不一致，解決方案：
Redis 服務器設置了一個 AOF 重寫緩衝區，這個緩衝區是在建立子進程後開始使用，當Redis服務器執行一個寫命令以後，就會將這個寫命令也發送到 AOF 重寫緩衝區。當子進程完成 AOF 重寫以後，就會給父進程發送一個信號，父進程接收此信號後，就會調用函數將 AOF 重寫緩衝區的內容都寫到新的 AOF 文件中
AOF優缺點
優勢：
- AOF 持久化的方法提供了多種的同步頻率，即便使用默認的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的數據而已
- AOF 文件使用 Redis 命令追加的形式來構造，所以，即便 Redis 只能向 AOF 文件寫入命令的片段，使用 redis-check-aof 工具也很容易修正 AOF 文件
- AOF 文件的格式可讀性較強，這也爲使用者提供了更靈活的處理方式。例如，若是咱們不當心錯用了 FLUSHALL 命令，在重寫還沒進行時，咱們能夠手工將最後的 FLUSHALL 命令去掉，而後再使用 AOF 來恢復數據。
缺點：
- 對於具備相同數據的的 Redis，AOF 文件一般會比 RDF 文件體積更大
- 在 Redis 的負載較高時，RDB 比 AOF 具好更好的性能保證
- AOF可能存在bug