Redis提供了兩種持久化方式：
RDB (Redis DataBase)
在指定的時間間隔內(nèi)生成數(shù)據(jù)集的時間點快照（point-in-time snapshot）AOP(Append Only File)
記錄服務(wù)器執(zhí)行的所有寫操作命令，并在服務(wù)器啟動時，通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。
Redis 還可以同時使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當(dāng) Redis 重啟時， 它會優(yōu)先使用 AOF 文件來還原數(shù)據(jù)集， 因為 AOF 文件保存的數(shù)據(jù)集通常比 RDB 文件所保存的數(shù)據(jù)集更完整。
RDB
Redis 會單獨的創(chuàng)建(fork) 一個子進程來進行持久化，會先將數(shù)據(jù)寫入到一個臨時文件中，待持久化過程結(jié)束了，再用這個臨時文件替換上次持久化還的文件。
整個過程中，主進程是不進行任何 IO 操作，這就確保了極高的性能，如果需要進行大規(guī)模的數(shù)據(jù)恢復(fù)，且對于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。
RDB 的缺點是最后一次持久化后的數(shù)據(jù)可能丟失。若當(dāng)前的進程的數(shù)據(jù)量龐大，那么 fork 之后數(shù)據(jù)量*2，此時就會造成服務(wù)器壓力大，運行性能降低。
fork 的作用是復(fù)制一個與當(dāng)前進程一樣的進程，新進程的所有數(shù)據(jù)(變量、環(huán)境變量、程序計數(shù)器等)數(shù)值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程。之所以不使用線程而選擇fork子進程，是利用了fork復(fù)制進程資源的特性，將redis當(dāng)前狀態(tài)拷貝一份，再持久化到文件中。而線程的做法就會破壞redis的單線程讀寫模型，造成對數(shù)據(jù)的競爭。
執(zhí)行：
-
開啟配置：
save 900 1 #900秒內(nèi)如果超過1個key被修改，則發(fā)起快照保存 save 300 10 #300秒內(nèi)容如超過10個key被修改，則發(fā)起快照保存 save 60 10000 #60秒內(nèi)容如超過10000個key被修改，則發(fā)起快照保存 命令執(zhí)行：
SAVE 直接調(diào)用rdbSave，阻塞Redis主進程看，直到保存完成為止。在主進程阻塞期間，服務(wù)器不能處理客戶端的任何請求。
BGSAVE 則fork 出一個子進程，子進程負(fù)責(zé)調(diào)用rdbSave ，并在保存完成之后向主進程發(fā)送信號，通知保存已完成。因為rdbSave 在子進程被調(diào)用，所以Redis 服務(wù)器在BGSAVE 執(zhí)行期間仍然可以繼續(xù)處理客戶端的請求。
AOP
AOF 則以協(xié)議文本的方式，將所有對數(shù)據(jù)庫進行過寫入的命令（及其參數(shù)）記錄到AOF文件，以此達(dá)到記錄數(shù)據(jù)庫狀態(tài)的目的。AOF文件其實可以認(rèn)為是Redis寫操作的日志記錄文件。
開啟配置：
appendonly yes //啟用aof持久化方式
# appendfsync always //每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用
appendfsync everysec //每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦
# appendfsync no //完全依賴os，性能最好,持久化沒保證
Rewrite
AOF 采用文件追加方式，文件會越來越來大。為避免出現(xiàn)此種情況，新增了重寫機制：當(dāng)aof 文件的大小超過所設(shè)定的閾值時，redis 就會自動 aof 文件的內(nèi)容壓縮，值保留可以恢復(fù)數(shù)據(jù)的最小指令集，可以使用命令bgrewirteaof。
重寫原理：aof 文件持續(xù)增長而大時，會fork出一條新進程來將文件重寫(也就是先寫臨時文件最后再rename)。重寫aof文件時并沒有讀取原來的文件，而是遍歷新進程的內(nèi)存中的數(shù)據(jù)，將其作為寫命令追加到文件，這點和快照有點類似。
觸發(fā)機制：redis 會記錄上次重寫的 aof 的大小，默認(rèn)的配置當(dāng) aof 文件大小上次 rewrite 后大小的一倍且文件大于 64M 觸發(fā)
no-appendfsync-on-rewrite no
# 重寫時是否可以運用 Appendfsync 用默認(rèn)no即可，保證數(shù)據(jù)安全
auto-aof-rewrite-percentage 100
# 重寫觸發(fā)的倍數(shù)
auto-aof-rewrite-min-size 64mb
# 設(shè)置基準(zhǔn)值大小
優(yōu)勢
AOP的優(yōu)勢在于使得Redis變得非?？煽浚耗憧梢栽O(shè)置不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執(zhí)行寫入命令時 fsync 。 AOF 的默認(rèn)策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，并且就算發(fā)生故障停機，也最多只會丟失一秒鐘的數(shù)據(jù)（ fsync 會在后臺線程執(zhí)行，所以主線程可以繼續(xù)努力地處理命令請求）
AOF 文件是一個只進行追加操作的日志文件（append only log）， 因此對 AOF 文件的寫入不需要進行 seek ， 即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復(fù)這種問題。
Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創(chuàng)建新 AOF 文件的過程中，會繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫過程中發(fā)生停機，現(xiàn)有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。
AOF 文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作， 這些寫入操作以 Redis 協(xié)議的格式保存， 因此 AOF 文件的內(nèi)容非常容易被人讀懂， 對文件進行分析（parse）也很輕松。 導(dǎo)出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執(zhí)行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那么只要停止服務(wù)器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。
缺點
對于相同的數(shù)據(jù)集來說，AOF 文件的體積通常要大于 RDB 文件的體積。
根據(jù)所使用的 fsync 策略，AOF 的速度可能會慢于 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負(fù)荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。
