◆ 持久化: 即把數據存儲於斷電後不會丟失的設備中,通常是硬盤.
◆ 常見的持久化方式:
主從:通過從服務器保存和持久化,如mongoDB的replication sets配置
日誌:操作生成相關日誌,並通過日誌來恢復數據
◆ Redis的持久化有2種方式：（1）rdb快照持久化 （2）日誌
------------------- rdb ------------------------
◆ rdb的工作原理:
每隔N分鐘或N次寫操作後，從內存dump數據形成rdb文件，壓縮，放在備份目錄。
rdb優勢在於：恢復速度很快！
【打開 redis.conf 配置文件】
◆ rdb快照相關參數
save 900 1 #刷新快照到硬盤中，必須滿足兩者要求才會觸發，即900秒之後至少1個關鍵字發生變化。
save 300 10 #必須是300秒之後至少10個關鍵字發生變化。
save 60 10000 #必須是60秒之後至少10000個關鍵字發生變化。
(如果這3個選項都屏蔽,則rdb禁用)
stop-writes-on-bgsave-error yes #後臺存儲錯誤停止寫（後臺備份進程出錯時,主進程停不停止寫入）
rdbcompression yes #使用LZF壓縮rdb文件。（導出的rdb文件是否壓縮）
rdbchecksum yes #存儲和加載rdb文件時校驗。（導入rbd恢復時數據時,要不要檢驗rdb的完整性）
dbfilename dump.rdb #設置rdb文件名。（導出來的rdb文件名）
dir ./ #設置工作目錄，rdb文件會寫入該目錄。（rdb的放置路徑）
◆ 測試案例
爲了方便測試，將 save 60 10000 改爲 save 60 3000.
此時測試寫入：
使用批量寫入工具可以方便測試：redis-benchmark
方法：./bin/redis-benchmark -n 10000 即可一次性寫入10000條數據！
此時，可以看到出現了一個 dump.rdb 文件：
接着繼續單個寫入：
然後，此時斷電了....
再次重新開啓服務後，會發現剛纔寫入的 set address 數據丟失了...
原因在於，60秒需要寫入3000條纔會保存，而此時並沒有3000條，所以並沒有保存。
於是，這就是rdb的缺陷。
◆ rdb的缺陷
在2個保存點之間,斷電,將會丟失1~N分鐘的數據
出於對持久化的更精細要求,redis增添了aof方式 append only file
------------------- aof ------------------------
◆ aof的原理
◆ 基本配置：
打開 redis.conf ，搜索 aof：
將上面的appendonly no 改爲 appendonly yes，並設置aof的保存目錄。
◆ aof的具體配置
appendonly no #是否打開 aof日誌功能（是否僅要日誌）
appendfsync always #每1個命令,都立即同步到aof. 安全,速度慢（系統不緩衝,直接寫,慢,丟失數據少）
appendfsync everysec #折中方案,每秒寫1次（折衷,每秒寫1次）
appendfsync no #寫入工作交給操作系統,由操作系統判斷緩衝區大小,統一寫入到aof. 同步頻率低,速度快。（系統緩衝,統一寫,速度快）
no-appendfsync-on-rewrite yes: #正在導出rdb快照的過程中,要不要停止同步aof（重寫aof時同步最新數據）
auto-aof-rewrite-percentage 100 #aof文件大小比起上次重寫時的大小,增長率100%時,重寫（當前aof文件是上次重寫是大N%時重寫）
auto-aof-rewrite-min-size 64mb #aof文件,至少超過64M時,重寫（aof重寫至少要達到的大小）
◆ 案例演示：
redis.conf 配置：
修改完成後保存退出，然後連接寫入數據，理論上1秒鐘就會有aof.
查看 appendonly.aof 文件：
假設剛寫入一個數據，然後斷電，重啓後，再查看，剛纔寫入的數據還是在的，說明用這個方法實現持久化還是很不錯的。
——→ 有個問題，如下：
就是說，同一個key，使用incre或其他命令，對這個key操作了N次，aof裏面就會寫入N次，這樣會導致aof文件很大。
假如此時這個age已經增長到100，那麼恢復時依然會從20，加1、加1... 一直增長到100
爲什麼不直接恢復爲100呢？方法如下：
把最終的結果逆化爲新的變量，可能是set，或者zset等等。此時相當於直接 set age 100。此過程叫做：aof重寫。
此時就需要用到上面配置文件裏的：
① auto-aof-rewrite-percentage 100 和 ② auto-aof-rewrite-min-size 64mb
① 假如上次aof的文件大小是2MB，那麼下次打到4MB則重寫，再下次8MB重寫，再下次16MB...
② 因爲前期文件較小，重寫的意義不大，所以使用後面的設置，當大於64MB的時候再重寫。當然此值可以配置。
其實還有一個命令：bgrewriteaof 可以直接馬上重寫。
* 之前沒有用到aof的時候，1秒鐘可以寫入1800條，但是打開aof並設置爲1秒鐘備份一次，測試結果1秒鐘可以寫入1300條，性能稍微會下降。
◆ 一些注意事項：
問: 在dump rdb過程中,aof如果停止同步,會不會丟失?
答: 不會,所有的操作緩存在內存的隊列裏, rdb執行dump完成後,統一操作.
問: aof重寫是指什麼?
答: aof重寫是指把內存中的數據,逆化成命令,寫入到.aof日誌裏.
以解決 aof日誌過大的問題.
問: rdb和aof，兩種是否可以同時用?
答: 可以,而且推薦這麼做
問: 如果rdb文件,和aof文件都存在,優先用誰來恢復數據?
答: aof
問: 恢復時rdb和aof哪個恢復的快
答: rdb快,因爲其是數據的內存映射,直接載入到內存,而aof是命令,需要逐條執行