前言

大家都知道Redis一個(gè)內(nèi)存數(shù)據(jù)庫(kù),它支持2種持久化方式：RDB(Snapshot 內(nèi)存快照) ，AOF(append only file)。持久化功能將內(nèi)存中的數(shù)據(jù)同步到磁盤來(lái)避免Redis發(fā)生異常導(dǎo)致數(shù)據(jù)丟失的情況。當(dāng)Redis實(shí)例重啟時(shí)，即可利用之前持久化的文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。

接下來(lái)，本文介紹兩種持久化的運(yùn)行機(jī)制和優(yōu)缺點(diǎn)。

一 RDB

RDB是默認(rèn)的持久化方式，按照一定的策略周期性的將內(nèi)存中的數(shù)據(jù)生成快照保存到磁盤。

每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次，并不 是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫操作比較多，必然會(huì)引起大量的磁盤io操作，可能會(huì)嚴(yán)重影響性能。

1.1 快照持久化過(guò)程

1.2 觸發(fā)機(jī)制

1. save 命令

當(dāng)客戶端向Redis server發(fā)送save命令請(qǐng)求進(jìn)行持久化時(shí)，由于Redis是用一個(gè)主線程來(lái)處理所有,save命令會(huì)阻塞Redis server處理其他客戶端的請(qǐng)求，直到數(shù)據(jù)同步完成。

2. bgsave命令

與save命令不同，bgsave是異步執(zhí)行的，當(dāng)執(zhí)行bgsave命令之后，Redis主進(jìn)程會(huì)fork 一個(gè)子進(jìn)程將數(shù)據(jù)保存到rdb文件中，同步完數(shù)據(jù)之后，對(duì)原有文件進(jìn)行替換，然后通知主進(jìn)程表示同步完成。

3. 自動(dòng)觸發(fā)

除了手動(dòng)觸發(fā)RDB持久化，Redis內(nèi)部還存在自動(dòng)觸發(fā)機(jī)制，

在配置中集中配置 save m n 的方式，表示 m秒內(nèi)數(shù)據(jù)集存在n次修改時(shí)，系統(tǒng)自動(dòng)觸發(fā)bgsave 操作。   

# 900s內(nèi)至少達(dá)到一條寫命令  
    save 900 1  
    # 300s內(nèi)至少達(dá)至10條寫命令  
    save 300 10  
    # 60s內(nèi)至少達(dá)到10000條寫命令  
    save 60 10000 

從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，主節(jié)點(diǎn)自動(dòng)執(zhí)行bgsave 生成RDB文件并發(fā)送給從節(jié)點(diǎn)

默認(rèn)情況下執(zhí)行 shutdown 命令時(shí)，如果沒有開啟AOF持久化功能，系統(tǒng)會(huì)自動(dòng)執(zhí)行bgsave命令。執(zhí)行debug reload 命令重新加載Redis時(shí)，也會(huì)自動(dòng)觸發(fā)save操作。

1.3 相關(guān)參數(shù)   

# 持久化 rdb文件遇到問題時(shí)，主進(jìn)程是否接受寫入，yes 表示停止寫入，如果是no 表示redis繼續(xù)提供服務(wù)。  
    stop-writes-on-bgsave-error yes  
    # 在進(jìn)行快照鏡像時(shí),是否進(jìn)行壓縮。yes:壓縮，但是需要一些cpu的消耗。no:不壓縮，需要更多的磁盤空間。  
    rdbcompression yes  
    # 一個(gè)CRC64的校驗(yàn)就被放在了文件末尾，當(dāng)存儲(chǔ)或者加載rbd文件的時(shí)候會(huì)有一個(gè)10%左右的性能下降，為了達(dá)到性能的最大化，你可以關(guān)掉這個(gè)配置項(xiàng)。  
    rdbchecksum yes  
    # 快照的文件名  
    dbfilename dump.rdb  
    # 存放快照的目錄  
    dir /var/lib/redis 

1.4 RDB的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

RDB文件小，非常適合定時(shí)備份，用于災(zāi)難恢復(fù)。

因?yàn)镽DB文件中直接存儲(chǔ)的是內(nèi)存數(shù)據(jù)，而AOF文件中存儲(chǔ)的是一條條命令，需要應(yīng)用命令。Redis加載RDB文件的速度比AOF快很多。

缺點(diǎn)

RDB持久化方式不能做到實(shí)時(shí)/秒級(jí)持久化。實(shí)時(shí)持久化要全量刷內(nèi)存到磁盤，成本太高。每秒fork子進(jìn)程也會(huì)阻塞主進(jìn)程，影響性能。

RDB文件是二進(jìn)制文件，隨著Redis不斷迭代有多個(gè)rdb文件的版本，不支持跨版本兼容。老的Redis無(wú)法識(shí)別新的RDB文件格式。

二 AOF

AOF(Append-only file)針對(duì)RDB的缺點(diǎn)做了優(yōu)化，在使用AOF持久化方式時(shí)，Redis會(huì)將每一個(gè)收到的寫操作命令都通過(guò)Write函數(shù)追加到文件最后，類似于MySQL的binlog。當(dāng)Redis重啟時(shí)會(huì)通過(guò)重新執(zhí)行文件中保存的寫命令來(lái)在內(nèi)存中重建整個(gè)數(shù)據(jù)庫(kù)的內(nèi)容。

2.1 AOF持久化過(guò)程

1. 客戶端發(fā)出 bgrewriteaof命令。

2. redis主進(jìn)程fork子進(jìn)程。

3. 父進(jìn)程繼續(xù)處理client請(qǐng)求，除了把寫命令寫入到原來(lái)的aof文件中。同時(shí)把收到的寫命令緩存到 AOF重寫緩沖區(qū)。這樣就能保證如果子進(jìn)程重寫失敗的話并不會(huì)出問題。

4. 子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新AOF文件中。

5. 當(dāng)子進(jìn)程把內(nèi)存快照寫入臨時(shí)文件中后，子進(jìn)程發(fā)信號(hào)通知父進(jìn)程。然后父進(jìn)程把緩存的寫命令也寫入到臨時(shí)文件。

6. 現(xiàn)在父進(jìn)程可以使用臨時(shí)文件替換老的aof文件，并重命名，后面收到的寫命令也開始往新的aof文件中追加。

2.2 相關(guān)參數(shù)   

# 是否開啟AOF，默認(rèn)關(guān)閉  
    appendonly yes  
    # 指定 AOF 文件名  
    appendfilename appendonly.aof  
    # Redis支持三種刷寫模式：  
    # appendfsync always #每次收到寫命令就立即強(qiáng)制寫入磁盤，類似MySQL的sync_binlog=1,是最安全的。但該模式下速度也是最慢的，一般不推薦使用。  
    appendfsync everysec #每秒鐘強(qiáng)制寫入磁盤一次，在性能和持久化方面做平衡，推薦該方式。  
    # appendfsync no     #完全依賴OS的寫入，一般為30秒左右一次，性能最好但是持久化最沒有保證，不推薦。  
    #在日志重寫時(shí)，不進(jìn)行命令追加操作，而只是將其放在緩沖區(qū)里，避免與命令的追加造成DISK IO上的沖突。  
    #設(shè)置為yes表示rewrite期間對(duì)新寫操作不fsync,暫時(shí)存在內(nèi)存中,等rewrite完成后再寫入，默認(rèn)為no，建議yes  
    no-appendfsync-on-rewrite yes  
    #當(dāng)前AOF文件大小是上次日志重寫得到AOF文件大小的二倍時(shí)，自動(dòng)啟動(dòng)新的日志重寫過(guò)程。  
    auto-aof-rewrite-percentage 100  
    #當(dāng)前AOF文件啟動(dòng)新的日志重寫過(guò)程的最小值，避免剛剛啟動(dòng)Reids時(shí)由于文件尺寸較小導(dǎo)致頻繁的重寫。  
    auto-aof-rewrite-min-size 64mb 

2.3 日志重寫

AOF機(jī)制將客戶端的每一個(gè)寫操作都追加到aof文件末尾，比如將一個(gè)key多次執(zhí)行incr,set命令,會(huì)寫入多次命令到aof文件，aof文件會(huì)越來(lái)越大，部分核心業(yè)務(wù)每天的寫入量有幾十G的大小。  

incr k1 1  
   set  k2 a  
   set  k2 b  
   incr k1 2  
   incr k1 3 
   set  k2 c  
   del  k3  
   ...  
   incr k1 100 

恢復(fù)Redis實(shí)例時(shí)，加載非常大的aof文件耗時(shí)會(huì)很長(zhǎng)。為了解決這個(gè)問題，Redis 支持aof文件重寫--把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新AOF文件中的過(guò)程。通過(guò)重寫，可以生成一個(gè)最小的命令集合。比如上面的幾個(gè)命令可以合并為 

incr k1 100  
  set  k2 c 

寫入數(shù)據(jù)的規(guī)則

1. 進(jìn)程內(nèi)過(guò)期的數(shù)據(jù)不用在寫入

2. 舊AOF文件含有的無(wú)效命令 del k1, set a 1, set a 2。重寫使用進(jìn)程內(nèi)的數(shù)據(jù)直接生成，aof文件就保留最新的命令集合。

3. 多條命令可以合并為一個(gè)命令，為了防止單個(gè)命令過(guò)大造成客戶端緩沖區(qū)溢出，對(duì)于list,set,hash,zset 等類型的操作，以64個(gè)元素為界拆分為多條。

觸發(fā)機(jī)制

1. 手動(dòng)觸發(fā) 執(zhí)行bgrewriteaof命令。

2. 根據(jù)配置自動(dòng)觸發(fā)

auto-aof-rewrite-min-size 表示運(yùn)行AOF重寫是文件最小的大小。默認(rèn)64M，小于64M就會(huì)不自動(dòng)重寫了。

auto-aof-rewrite-percentage 表示（aof_current_size- aof_base_size） / aof_base_size 的比值。

aof文件重寫之后當(dāng)前文件大小增長(zhǎng)多少就觸發(fā)重寫

自動(dòng)觸發(fā)時(shí)機(jī) :

aof_current_size>auto-aof-rewrite-min-size 

&& 

(aof_current_size - aof_base_size) /  aof_base_size >= auto-aof-rewrite-percentage

三 RDB VS AOF 對(duì)比

具體使用哪種持久化方式 ，下面是來(lái)自官方的建議：

通常，如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時(shí)使用兩種持久化方式。如果你可以接受災(zāi)難帶來(lái)的幾分鐘的數(shù)據(jù)丟失，那么你可以僅使用RDB。很多用戶僅使用了AOF，但是我們建議，既然RDB可以時(shí)不時(shí)的給數(shù)據(jù)做個(gè)完整的快照，并且提供更快的重啟，所以最好還是也使用RDB。

生產(chǎn)上的實(shí)例大多不會(huì)是單點(diǎn)，而是主從，也有利用slave作為持久化方式，同時(shí)滿足HA的需求。讀者朋友可以分享一下各自遇到的和 redis 持久化相關(guān)的問題。

最后推薦一本書 ,非常適合運(yùn)維朋友學(xué)習(xí)。