單例模式 (Singleton pattern)
Redis 是記憶體資料庫，如果不將記憶體中的資料庫狀態儲存到磁碟，那麼一旦伺服器程序退出，伺服器中的資料庫狀態也會消失。所以 Redis 提供了持久化功能！
RDB（Redis DataBase）
在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀到記憶體裡。
Redis會單獨建立（fork）一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。整個過程中，主程序是不進行任何IO操作的。這就確保了極高的效能。如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失。
rdb儲存的檔案是dump.rdb 都是在配置檔案中可以配置
觸發機制
1.save的規則滿足的情況下，會自動觸發rdb規則
2.執行flushall命令，也會觸發rdbguize
3.退出redis，也會產生rdb檔案
備份就會自動生成一個dump.rdb
恢復rdb檔案
1.將備份檔案（dump.rdb）移動到redis安裝目錄並啟動服務即可
2.CONFIG GET dir 獲取目錄
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/www/server/redis"
優缺點：
優點：
1、適合大規模的資料恢復
缺點：
1、在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最後一次快照後的所有修改
2、fork程序的時候，會佔用一定的記憶體空間
AOF（Append Only File）
將我們的所有命令都記錄下來，恢復的時候把這個檔案重新執行一遍
以日誌的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來（讀操作不記錄），只許追加檔案但不可以改寫檔案，redis啟動之初會讀取該文重新構建資料，換言之，redis重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作
預設此方式是關閉的，重啟redis，即可生效
如果aof檔案有錯誤，這時候redis是無法正常啟動的，需要修復aof檔案。
redis-check-aof --fix來修復aof檔案
重寫機制
AOF 採用檔案追加方式，檔案會越來越大，為避免出現此種情況，新增了重寫機制，當AOF檔案的大小
超過所設定的閾值時，Redis 就會啟動AOF 檔案的內容壓縮，只保留可以恢復資料的最小指令集，
原理：AOF 檔案持續增長而過大時，會fork出一條新程序來將檔案重寫、
優缺點
優點：
appendfsync always #每次修改都會sync。消耗效能
appendfsync everysec #每一秒執行一次sync,可能會丟失這1s資料
appendfsync no #不執行sync，這個時候作業系統自己同步資料，速度最快
缺點：
1.相對於資料檔案來說，aof遠遠大於rdb，修復速度更慢一些。
2.aof執行效率更慢一些（I/O操作）
總結
1、RDB 持久化方式能夠在指定的時間間隔內對你的資料進行快照儲存
2、AOF 持久化方式記錄每次對伺服器寫的操作，當伺服器重啟的時候會重新執行這些命令來恢復原始的資料，AOF命令以Redis 協議追加儲存每次寫的操作到檔案末尾，Redis還能對AOF檔案進行後臺重寫，使得AOF檔案的體積不至於過大。
3、只做快取，如果你只希望你的資料在伺服器執行的時候存在，你也可以不使用任何持久化
4、同時開啟兩種持久化方式
在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料，因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。
RDB 的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案，那要不要只使用AOF呢？建議不要，因為RDB更適合用於備份資料庫（AOF在不斷變化不好備份），快速重啟，而且不會有AOF可能潛在的Bug，留著作為一個萬一的手段。
5、效能建議
因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠了，只保留 save 900 1 這條規則。
如果Enable AOF ，好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動指令碼較簡單隻load自己的AOF檔案就可以了，代價一是帶來了持續的IO，二是AOF rewrite 的最後將 rewrite 過程中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上，預設超過原大小100%大小重寫可以改到適當的數值。
如果不Enable AOF ，僅靠 Master-Slave Repllcation 實現高可用性也可以，能省掉一大筆IO，也減少了rewrite時帶來的系統波動。代價是如果Master/Slave 同時倒掉，會丟失十幾分鐘的資料，啟動指令碼也要比較兩個 Master/Slave 中的 RDB檔案，載入較新的那個，微博就是這種架構。