一、RDB快照模式RDB方式原理：當redis需要做持久化時（執行SAVA或者BGSAVA命令，或者是達到配置條件時執行），redis會fork一個子程序，子程序將資料寫到磁碟上一個臨時RDB檔案中，當子程序完成寫臨時檔案後，將原來的RDB替換掉（預設檔名為dump.rdb）RDB備份條件和命令：1、執行SAVE命令，在當前執行緒執行，會卡住2、執行BGSAVE命令，在後臺執行緒執行，馬上返回3、當符合使用者給定的配置條件時Redis會自動將記憶體中的所有資料進行快照並存儲在硬碟上。由兩個引數構成：時間和改動的鍵的個數。當在指定的時間內被更改的鍵的個數大於指定的數值時就會進行快照，在配置檔案redis.conf中已經預置了3個條件：

save 900 1 # 900秒內有至少1個鍵被更改則進行快照 save 300 10 # 300秒內有至少10個鍵被更改則進行快照 save 60 10000 # 60秒內有至少10000個鍵被更改則進行快照RDB優缺點：定時備份，Redis效率高，但是容易造成資料丟失，丟失的多少和備份策略有關，例如：5分鐘備份一次，但是第8分時宕機了，那麼就丟失了後面的3分鐘資料一、AOF模式AOF方式原理：AOF就可以做到全程持久化，Redis每執行一個修改資料的命令，都會把這個命令新增到AOF檔案中，當Redis重啟時，將會讀取AOF檔案進行“重放”以恢復到 Redis關閉前的最後時刻。由於os會在核心中快取 write做的修改，所以可能不是立即寫到磁碟上。這樣aof方式的持久化也還是有可能會丟失部分修改。不過我們可以通過配置檔案告訴redis我們想要 通過fsync函式強制os寫入到磁碟的時機。有三種方式如下（預設是：每秒fsync一次）appendonly yes              //啟用aof持久化方式# appendfsync always      //每次收到寫命令就立即強制寫入磁碟，最慢的，但是保證完全的持久化，不推薦使用appendfsync everysec     //每秒鐘強制寫入磁碟一次，在效能和持久化方面做了很好的折中，推薦# appendfsync no    //完全依賴os，效能最好,持久化沒保證AOF優缺點AOF基本可以保證資料不丟失，但是AOF持久化檔案會變的越來越大。例如我們呼叫incr test命令100次，檔案中必須儲存全部的100條命令，其實有99條都是多餘的。