一、概念
一）redis提供了不同級別的持久化方式：
- RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲。
- AOF持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候會重新執行這些命令來恢復原始的數據，AOF命令以redis協議追加保存每次寫的操作到文件末尾，redis還能對AOF文件進行后台重寫，使得AOF文件的體積不至於過大。
- 如果你只希望你的數據在服務器運行的時候存在，你也可以不適用任何持久化方式。
- 也可以同時開啟兩種持久化方式，在這種情況下，當redis重啟的時候會有限載入AOF文件來恢復原始的數據，因為在通常情況下AOF文件保存的數據集比RDB文件保存的數據集要完整
二）RDB的優缺點
優點：
- RDB是一個非常緊湊的文件，它保存了某個時間點的數據集，非常適用於數據集的備份，這樣即使出了問題你也可以根據需求恢復到不同版本的數據集。
- RDB是一個緊湊的單一文件，很方便傳送到另一個遠端數據中心或者亞馬遜的S3（可能加密），非常適用於災難恢復。
- RDB在保存RDB文件時父進程唯一需要做的就是fork出一個子進程，接下來的工作全部由子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
- 與AOF相比，在恢復大的數據集的時候，RDB方式會更快一些。
缺點：
- 如果希望在redis意外停止工作的情況下丟失的數據最少的話，那么RDB不適合
- RDB需要經常fork子進程來保存數據集到硬盤上，當數據集比較大的時候，fork的過程是非常耗時的，可能會導致redis在一些毫秒級內不能相應客戶端的請求。
三）AOF的優缺點
優點：
- 使用AOF會讓你的redis更加耐久
- AOF文件是一個只進行追加的日志文件，所以不需要寫入seek，即使由於某些原因（磁盤空間已滿，寫的過程中宕機等）未執行完整的寫入命令，你也可使用redis-check-aof工具修復這些問題。
- redis可以在aof文件體積變得過大時，自動的在后台對aof進行重寫。
- aof文件有序地保存了對數據庫執行的所有寫入操作，這些寫入操作以redis協議的格式保存，因此aof文件的內容非常容易被人讀懂，對文件進行分析（parse）也很輕松。
缺點：
- 對於相同的數據集來說，aof文件的體積通常要大於rdb文件的體積。
- 根據所使用的fsync策略，aof的速度可能會慢於rdb
四）如何選擇使用哪種持久化方式：
- 一般來說，如果想達到足以媲美PostgreSQL的數據安全性，你應該同時使用兩種持久化功能。
- 如果非常關心你的數據，但仍然可以承受數分鍾以內的數據丟失，那么你可以只使用RDB持久化。
- 不推薦只是用AOF持久化，因為定時生成RDB快照（snapshot）非常便於進行數據庫備份，並且RDB恢復數據集的速度也要比AOF恢復的速度要快。
五）更多RDB細節：
- 在默認情況下，redis將數據庫快照保存在名字為dump.rdb的二進制文件中。
- 這種持久化方式被稱為快照snapshotting
- 當redis需要保存dump.rdb文件時，服務器執行以下操作：
-
- redis調用forks，同時擁有父進程和子進程。
- 子進程將數據集寫入到一個臨時RDB文件中。
- 當子進程完成對新RDB文件的寫入是，redis用新RDB文件替換原來的RDB文件，並刪除舊的RDB文件
二、redis數據持久化相關配置以及命令
一）RDB的配置：
1、在配置文件中已經預設三個條件
- save 900 1 #15分鍾內至少有一個鍵被更改
- save 300 10 #5分鍾內至少有10個鍵被更改
- save 60 10000 #1分鍾內至少有10000個鍵被更改
2、默認的rdb文件路徑是當前目錄，文件名是：dump.rdb，可以在配置文件中修改路徑和文件名，分別是dir和dbfilename
- dir ./ #rdb文件存儲路徑
- dbfilename dump.rdb #rdb文件名
3、RDB文件的壓縮：
- RDB文件是通過壓縮的，可以通過配置rdbcompression參數來禁用壓縮，redis默認是開啟壓縮的。
4、RDB相關命令：
- 如果沒有觸發自動快照，需要對redis執行手動快照操作，save和bgsave都是執行手動快照，但是兩者有區別：可以通過save和bgsave命令來手動快照，兩個命令的區別是前者是由主進程進行快照，會阻塞其他請求，后者是通過fork子進程進行快照。
二）AOF（Append-Only File）
1、快照功能並不是非常耐久（dura ble）：如果redis因為某些原因而造成故障停機，那么服務器將丟失最近寫入、且仍未保存到快照中的那些數據。從1.1版本開始，redis增加了一種完全耐久的持久化方式：AOF持久化。
2、可以在配置文件中打開AOF方式：
- appendonly yes
3、從現在開始，每當redis執行一個改變數據集的命令時（比如set），這個命令就會被追加到AOF文件的末尾。
4、AOF工作原理：
1）redis執行fork(),現在同時擁有父進程和子進程
2）子進程開始將新AOF文件的內容寫入到臨時文件
3）對於所有新執行的寫入命令，父進程一邊將他們累積到一個內存緩存中，一邊將這些改動追加到現有AOF文件的末尾，這樣即使在重寫的中途發生停機，現有的AOF文件也還是安全的
4）當子進程完成重寫工作時，它給父進程發送一個信號，父進程在接收到信號之后，將內存緩存中的所有數據追加到新AOF文件的末尾
5、日志重寫
1）AOF文件的體積會變得越來越大
2）重建（rebuild）
3）bgrewriteaof命令
4）自動觸發AOF重寫
6、AOF相關配置
1）AOF文件的位置和RDB的位置相同，都是通過dir參數設置，默認的文件名是appendonly.aof,可以通過appendfilename參數修改
2）重寫策略的參數設置
- auto-aof-rewrite-percentage 100
- 當前的AOF文件大小超過上一次重寫的AOF文件大小的百分之多少時會再次進行重寫，如果之前沒有重寫過，則以啟動時的AOF大小為依據
- auto-aof-rewrite-min-size 64mb
- 限制了允許重寫的最小AOF文件
3）文件同步策略
- 文件寫入默認情況下會先寫入到系統的緩存中，系統每個30秒同步一次，才是真正的寫入到磁盤，如果在這30秒服務器宕機那數據也會丟失
- appendfsync always每次都同步（最安全但是最慢）
- appendfsync everysec每秒同步（默認的同步策略）
- appendfsync no 不主動同步，由操作系統來決定（最快但是不安全）
7、優化AOF文件：
- 可以使用BGREWRITEAOF命令來重寫AOF文件。目的是去除數據的中間執行過程，保存最終數據命令即可。
8、AOF文件損壞
1）為現有的AOF文件創建一個備份
2）使用redis-check-aof修復
- redis-check-aof --fix
- （可選）使用diff -u對比修復后的AOF文件和原始AOF文件的額備份，查看兩個文件之間的不同之處。
- 重啟redis服務器，等待服務器載入修復后的AOF文件，並進行數據恢復。
9、怎樣從RDB方式切換為AOF方式：
1）為最新的dump.rdb文件創建一個備份
2）將備份放到一個安全的地方
3）執行以下兩條命令
- redis-cli config set appendonly yes
- redis-cli config set save ""
4）確保寫命令會被正確的追加到AOF文件的末尾
三、redis數據備份
一）數據備份
1、確保你的數據由完整的備份（磁盤故障，節點失效，諸如此類的問題都可能使數據丟失，不進行備份是非常危險的）
2、無論何時，賦值RDB文件都是絕對安全的。
二）備份步驟
1）創建一個定期任務，每小時將一個RDB文件備份到一個文件夾，並且每天將一個RDB文件備份到另一個文件夾。
2）確保快照的備份都帶有相應的日期和時間信息，每次執行定期任務腳本是，使用find命令來刪除過期的快照：比如說，可以保留最近48小時內的每小時快照，還可以保留最近一兩個月的每日快照。
3）至少每天一次，將RDB備份到你的數據中心之外，或者至少是備份到你運行redis服務器的屋里機器之外
三）容災備份：
1）對數據進行備份，並將這些備份傳送到多個不同的外部數據中心。
2）容災備份可以在redis運行並產生快照的主數據中心發生嚴重的問題是，仍然讓數據處於安全狀態。
四）容災備份方法：
1）Amazon S3
2）傳送快照可以使用SCP來完成（ssh的組件）
3）在文件傳送完畢之后，檢查所傳送備份文件的體積和原始文件的體積是否相同。