持久化之RDB:
RDB(Redis Data Base)
配置文件：dump.rdb
是什麼：
在指定的時間間隔內將內存中的數據集快照寫入磁盤，
也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存裏
RDB的缺點是最後一次持久化後的數據可能丟失。
SNAPSHOTTING快照
如何觸發RDB快照(備份):
1 可以cp dump.rdb dump_new.rdb
2 Save：save時只管保存，其它不管，全部阻塞
動態所有停止RDB保存規則的方法：redis-cli config set save ""
3 BGSAVE：Redis會在後臺異步進行快照操作，
快照同時還可以響應客戶端請求。可以通過lastsave
命令獲取最後一次成功執行快照的時間
默認的快照配置：
是1分鐘內改了1萬次，
或5分鐘內改了10次，
或15分鐘內改了1次。
PS:執行flushall命令，也會產生dump.rdb文件，但裏面是空的，無意義
優勢：
適合大規模的數據恢復
對數據完整性和一致性要求不高
劣勢：
fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮
持久化之AOF:
AOF(Append Only File)
配置文件：appendonly.aof
是什麼：
以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啓動之初會讀取該文件重新構建數據，換言之，redis重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作
修復命令：redis-check-aof --fix appendonly.aof
--fix可以直接進行修復 不加此參數僅檢查
Rewrite
AOF採用文件追加方式，文件會越來越大爲避免出現此種情況，新增了重寫機制,
當AOF文件的大小超過所設定的閾值時，Redis就會啓動AOF文件的內容壓縮，
只保留可以恢復數據的最小指令集.可以使用命令bgrewriteaof
重寫原理:
AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最後再rename)，遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操作，並沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似
觸發機制:
Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發
RDB和AOF的總結
RDB的數據不實時 如果宕機可能丟失很多數據（Fork出一條和當前操作進程一模一樣的進程來進行RDB持久化）
AOF每秒更新 頻繁IO 消耗性能（Fork出一條進程來記錄增刪改操作 寫入appendonly.aof）
性能建議：
因爲RDB文件只用作後備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啓動腳本較簡單隻load自己的AOF文件就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值。
如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啓動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構