Redis中數據的持久化有兩種方式；RDB（Redis DataBsse） 和 AOF（Append Only File），默認采取的是RDB方式

RDB

　　1.是什麽：在指定的時間間隔內將內存中的數據集快照寫入磁盤，

　　也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存裏

　　Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，

　　待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。

　　整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能，如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

　　RDB的缺點是最後一次持久化後的數據可能丟失。

　　2.Fork

　　　　fork的作用是復制一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）數值都和原進程一致，但是是一個全新的進程，並作為原進程的子進程

　　3.RDB保存的是dump.rdb文件

　　4.配置位置（在前面有提到配置文件中 SNAPSHOTING快照的相關配置）

　　5.如何觸發RDB快照（Redis的啟動默認不會創建RDB文件）

　　　　a）配置文件中默認的快照配置　　冷拷貝後重新使用　　cp dump.rdb dump_new.rdb

　　　　b）save命令 或者是 bgsave：

　　　　　　save：save時只管保存，其他不管，其他全部阻塞

　　　　　　bgsave：Redis會在後臺進行快照操作，快照同時還可以響應客戶端請求。可以通過lastsave命令獲取最後一次成功執行快照的時間

　　　　c）執行flushall命令也會產生dump.rdb文件，但裏面是空的，無意義

　　　　d）Redis的關閉 ： shutdown命令執行，本質上相當於執行了commit，會把那些已經執行了，但是還有沒有存到dump.rdb中的數據，commit到RDB中 類似於執行了一個save

　　6.如何恢復　　將備份文件 (dump.rdb) 移動到 redis 安裝目錄並啟動服務即可　　CONFIG GET dir獲取目錄

　　7.優勢：適合大規模的數據恢復 對數據完整性和一致性要求不高時使用

　　8.劣勢：在一定時間間隔做一次備份，所以如何Redis意外 down 掉的話，就會丟失最後一次快照後的所有修改

　　　　　　fork的時候，內存中的數據被克隆了一份，大致兩倍的膨脹性需要考慮

　　9.如何停止；動態停止RDB所有保存規則的方法 redis-cli config set save ""

AOF

　　a）是什麽

　　以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作

　　AOF保存的是 appendonly.aof文件（按照策略進行保存）（默認每秒保存一次）

　　b）AOF啟動/修復/恢復

　　　　AOF啟動：修改默認的 appendonly no ，改為yes

　　　　正常恢復

　　　　　　將有數據的aof文件復制一份保存到對應目錄(config get dir)

　　　　　　恢復：重啟redis然後重新加載

　　　　異常恢復

　　　　　　備份被寫壞的AOF文件

　　　　　　修復：redis-check-aof --fix

　　　　　　恢復：重啟redis然後重新加載

　　c）rewrite（重寫來完成文件壓縮）

　　　　AOF采用文件追加方式，文件會越來越大為避免出現此種情況，新增了重寫機制,當AOF文件的大小超過所設定的閾值時，Redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集.可以使用命令bgrewriteaof

　　　　AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最後再rename)，遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操作，並沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似

　　　　觸發機制：Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發

　　d）使用AOF方式持久化的優勢，采用的三種策略

　　　　1.每修改同步：appendfsync always 同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好

　　　　2.每秒同步：appendfsync everysec 異步操作，每秒記錄 如果一秒內宕機，有數據丟失

　　　　3.不同步：不同步：appendfsync no 從不同步，依賴系統記錄（30秒）

　　e）劣勢：

　　　　相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢於rdb

　　　　aof運行效率要慢於rdb,每秒同步策略效率較好，不同步效率和rdb相同

兩種持久化方式總結：

　　1.RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲

　　2.AOF持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候或重新執行一遍這些命令來恢復原始的數據

　　　AOF命令以redis協議追加保存每次寫的操作 到文件末尾

　　　Redis 還能對AOF文件進行後臺重寫，使得AOF文件的體積不至於過大

只做緩存:如果你只希望你的數據在服務器運行的時候存在，關閉服務器就銷毀，可以不適用任何的持久化方式

如果同時開啟兩種持久化：

　　在這種情況下,當redis重啟的時候會優先載入AOF文件來恢復原始的數據,因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.RDB的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件。那要不要只使用AOF呢？

作者建議不要，因為RDB更適合用於備份數據庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。

性能建議：

　　因為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文件，載入較新的那個。新浪微博就選用了這種架構

5.Redis的持久化