大家都知道redis一個內存數據庫,它支持2種持久化方式： RDB(Snapshot 內存快照) ， AOF(Append only file) 。持久化功能將內存中的數據同步到磁盤來避免Redis發生異常導致數據丟失的情況。當Redis實例重啟時，即可利用之前持久化的文件實現數據恢復。
接下來，本文介紹兩種持久化的運行機制和優缺點。
一 RDB
RDB是默認的持久化方式，按照一定的策略周期性的將內存中的數據生成快照保存到磁盤。
每次快照持久化都是將內存數據完整寫入到磁盤一次，并不 是增量的只同步臟數據。如果數據量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴重影響性能。
1.1 快照持久化過程
1.2 觸發機制
1. save 命令
當客戶端向Redis server發送save命令請求進行持久化時，由于Redis是用一個主線程來處理所有,save命令會阻塞Redis server處理其他客戶端的請求，直到數據同步完成。
2. bgsave命令
與save命令不同，bgsave是異步執行的，當執行bgsave命令之后，Redis主進程會fork 一個子進程將數據保存到rdb文件中，同步完數據之后，對原有文件進行替換，然后通知主進程表示同步完成。
3. 自動觸發
除了手動觸發RDB持久化，Redis內部還存在自動觸發機制，
在配置中集中配置 save m n 的方式，表示 m秒內數據集存在n次修改時，系統自動觸發bgsave 操作。
從節點執行全量復制操作，主節點自動執行bgsave 生成RDB文件并發送給從節點
默認情況下執行 shutdown 命令時，如果沒有開啟AOF持久化功能，系統會自動執行bgsave命令。執行debug reload 命令重新加載Redis時，也會自動觸發save操作。
1.3 相關參數
1.4 RDB的優缺點
優點
RDB文件小，非常適合定時備份，用于災難恢復。
因為RDB文件中直接存儲的是內存數據，而AOF文件中存儲的是一條條命令，需要應用命令。Redis加載RDB文件的速度比AOF快很多。
缺點
RDB持久化方式不能做到實時/秒級持久化。實時持久化要全量刷內存到磁盤，成本太高。
每秒fork子進程也會阻塞主進程，影響性能。RDB文件是二進制文件，隨著Redis不斷迭代有多個rdb文件的版本，
不支持跨版本兼容。老的Redis無法識別新的RDB文件格式。
二 AOF
AOF(Append-only file)針對RDB的缺點做了優化，在使用AOF持久化方式時，Redis會將每一個收到的 寫操作命令 都通過Write函數追加到文件最后，類似于MySQL的binlog。當Redis重啟時會通過重新執行文件中保存的 寫命令 來在內存中重建整個數據庫的內容。
2.1 AOF持久化過程
1. 客戶端發出 bgrewriteaof命令。
2. redis主進程fork子進程。
3. 父進程繼續處理client請求，除了把寫命令寫入到原來的aof文件中。同時把收到的寫命令緩存到 AOF重寫緩沖區 。這樣就能保證如果子進程重寫失敗的話并不會出問題。
4. 子進程根據內存快照，按照命令合并規則寫入到新AOF文件中。
5. 當子進程把內存快照寫入臨時文件中后，子進程發信號通知父進程。然后父進程把緩存的寫命令也寫入到臨時文件。
6. 現在父進程可以使用臨時文件替換老的aof文件，并重命名，后面收到的寫命令也開始往新的aof文件中追加。
2.2 相關參數
2.3 日志重寫
AOF機制將客戶端的每一個寫操作都追加到aof文件末尾，比如將一個key多次執行incr,set命令,會寫入多次命令到aof文件，aof文件會越來越大，部分核心業務每天的寫入量有幾十G的大小。
恢復Redis實例時，加載非常大的aof文件耗時會很長。為了解決這個問題，Redis 支持aof文件重寫--把Redis進程內的數據轉化為寫命令同步到新AOF文件中的過程。通過重寫，可以生成一個最小的命令集合。比如上面的幾個命令可以合并為
寫入數據的規則
1. 進程內過期的數據不用在寫入
2. 舊AOF文件含有的無效命令 del k1, set a 1, set a 2。重寫使用進程內的數據直接生成，aof文件就保留最新的命令集合。
3. 多條命令可以合并為一個命令，為了防止單個命令過大造成客戶端緩沖區溢出，對于list,set,hash,zset 等類型的操作，以64個元素為界拆分為多條。
觸發機制
1. 手動觸發 執行bgrewriteaof命令。
2. 根據配置自動觸發
auto-aof-rewrite-min-size 表示運行AOF重寫是文件最小的大小。默認64M，小于64M就會不自動重寫了。
auto-aof-rewrite-percentage 表示（ aof_current_size - aof_base_size ） / aof_base_size 的比值。
aof文件重寫之后當前文件大小增長多少就觸發重寫
自動觸發時機 :
aof_current_size > auto-aof-rewrite-min-size
&&
( aof_current_size - aof_base_size ) / aof_base_size >= auto-aof-rewrite-percent
age
三 RDB VS AOF 對比
具體使用哪種持久化方式 ，下面是來自官方的建議：
通常，如果你要想提供很高的數據保障性，那么建議你同時使用兩種持久化方式。如果你可以接受災難帶來的幾分鐘的數據丟失，那么你可以僅使用RDB。很多用戶僅使用了AOF，但是我們建議，既然RDB可以時不時的給數據做個完整的快照，并且提供更快的重啟，所以最好還是也使用RDB。
生產上的實例大多不會是單點，而是主從，也有利用slave作為持久化方式，同時滿足HA的需求。讀者朋友可以分享一下各自遇到的和 redis 持久化相關的問題。
