概述
Redis 主要用途是在記憶體中儲存資料，對資料的儲存就需要有可靠性，不會出現資料的丟失和錯誤。但我們都知道 Redis 的高效能來源於其將資料儲存在記憶體中，一旦應用程式關閉（這可能是應用程式崩潰、或伺服器主機異常引起的意外中斷）會導致資料丟失。這時候資料的持久化就顯得尤其重要了，資料持久化是指將記憶體中的資料備份在磁碟中一份，當下次啟動 redis 時會從磁碟中讀取資料，寫入記憶體，從而實現資料的恢復。
Redis 的持久化有兩種方式 RDB 和 AOF，RDB 是將記憶體資料集的快照主動或被動的按某些條件備份到磁碟中；AOF 是將 Redis 所有的資料更改命令儲存在檔案中，當下次啟動 Redis 時就會執行檔案中的所有命令來達到還原資料的效果
RDB 持久化
RDB 資料的備份分為手動和被動兩種方式
手動觸發
使用 save 命令可以手動觸發備份資料
save 命令會阻塞 Redis 伺服器程式，直到 RDB 的檔案建立完成，期間不能執行其他任何命令請求。
如果希望不阻塞 Redis 伺服器程式，可以使用bgsave 命令
bgsave 命令會建立一個子程式，由子程式來建立 RDB 檔案，父程式可以繼續處理其他請求。
這時我們就可以在 Redis 安裝目錄下看到 dump.rdb 檔案，當下次啟動 Redis 時就會載入改檔案的資料
被動觸發
被動觸發是指達到一定的條件時，Redis 會自動備份資料。
在 Redis 的配置檔案 Redis.conf 中我們可以看到如下配置
其中的含義分別為：
save 900 1 在900秒內發生一次資料變更執行備份
save 300 10 在300秒內發生10次資料變更執行備份
save 60 10000 在60秒內發生10000次資料變更執行備份
AOF 持久化
Redis 伺服器預設開啟 RDB，關閉 AOF。要開啟 AOF 備份，需要修改配置檔案。
設定配置檔案中的 appendonly 為 yes
更改完配置檔案後重啟 Redis 服務，我們可以在安裝目錄下看到 appendonly.aof 檔案，當我們執行新增、更改和刪除資料命令時，Redis 會將命令寫入 appendonly.aof 檔案中。
重啟服務後，依然可以 get 到改資料
兩種持久化的選擇
RDB 與 AOF 的區別
RDB 方式
優點：RDB 的資料儲存檔案緊湊，體積小，網路傳輸快，適合全量複製；RDB 的資料恢復速度要比 AOF 快很多。RDB 持久化對 Rdis 效能的影響較小。
缺點：RDB 檔案的致命缺點就是資料的持久化無法做到實時儲存，會出現資料丟失，這對系統中的重要資料來說是致命的。
AOF 方式
優點：AOF 持久化支援秒級的持久化，資料可實時儲存。
缺點：備份檔案大，啟動時資料恢復慢，對 Redis 的效能影響大。
實際應用中應該如何選擇
無論是 RDB 還是 AOF，開啟持久化必然對效能方面造成一定的影響。從應用需求和硬體條件綜合來考慮。
下面分場景來討論持久化策略的選擇，下面的討論也只是作為參考，實際方案可能更復雜更具多樣性。
（1）如果Redis中的資料完全丟棄也沒有關係（如Redis完全用作DB層資料的cache），那麼無論是單機，還是主從架構，都可以不進行任何持久化。
（2）在單機環境下（對於個人開發者，這種情況可能比較常見），如果可以接受十幾分鍾或更多的資料丟失，選擇RDB對Redis的效能更加有利；如果只能接受秒級別的資料丟失，應該選擇AOF。
（3）但在多數情況下，我們都會配置主從環境，slave的存在既可以實現資料的熱備，也可以進行讀寫分離分擔Redis讀請求，以及在master宕掉後繼續提供服務。
在這種情況下，一種可行的做法是：
master（主伺服器）：完全關閉持久化（包括RDB和AOF），這樣可以讓master的效能達到最好
slave（從伺服器）：關閉RDB，開啟AOF（如果對資料安全要求不高，開啟 RDB 關閉 AOF 也可以），並定時對持久化檔案進行備份（如備份到其他資料夾，並標記好備份的時間）；然後關閉 AOF 的自動重寫，然後新增定時任務，在每天Redis閒時（如凌晨12點）呼叫 bgrewriteaof。
本作品採用《CC 協議》，轉載必須註明作者和本文連結