Redis的強勁性能很大程度上是由于它所有的資料都存盤在記憶體中，當然如果redis重啟或者服務器故障導致redis重啟，所有存盤在記憶體中的資料就會丟失，但是在某些情況下，我們希望Redis在重啟后能夠保證資料不會丟失，

將redis作為nosql資料庫使用，
將Redis作為高效快取服務器，快取被擊穿后對后端資料庫層面的瞬時壓力是特別大的，所有快取同時失效可能會導致雪崩，

這時我們希望Redis能將資料從記憶體中以某種形式同步到硬碟上，使得重啟后可以根據硬碟中的記錄來恢復資料，

Redis支持兩種方式的持久化，一種是RDB方式、另一種是AOF（append-only-file）方式，兩種持久化方式可以單獨使用其中一種，也可以將這兩種方式結合使用，

RDB：根據指定的規則“定時”將記憶體中的資料存盤在硬碟上，
AOF：每次執行命令后將命令本身記錄下來，

RDB模式

RDB的持久化方式是通過快照（snapshotting）完成的，它是Redis默認的持久化方式，配置如下，

# save 3600 1
# save 300 100
# save 60 10000

Redis允許用戶自定義快照條件，當符合快照條件時，Redis會自動執行快照操作，快照的條件可以由用戶在組態檔中配置，配置格式如下

save <seconds> <changes>

第一個引數是時間視窗，第二個是鍵的個數，也就是說，在第一個時間引數配置范圍內被更改的鍵的個數大于后面的changes時，即符合快照條件，當觸發條件時，Redis會自動將記憶體中的資料生成一份副本并存盤在磁盤上，

這個程序稱之為“快照”，除了上述規則之外，還有以下幾種方式生成快照，

根據配置規則進行自動快照
用戶執行SAVE或者GBSAVE命令
執行FLUSHALL命令
執行復制(replication)時

根據配置規則進行自動快照

修改redis.conf檔案，表示5秒內，有一個key發生變化，就會生成rdb檔案，

  save 5 1                # 表示3600s以內至少發生1個key變化（新增、修改、洗掉），則重寫rdb檔案
  save 300 100
  save 60 10000

修改檔案存盤路徑
```
dir /data/program/redis/bin
```

其他引數配置說明

引數	說明
dir	rdb檔案默認在啟動目錄下（相對路徑） `config get dir` 獲取
dbfilename	檔案名稱
rdbcompression	開啟壓縮可以節省存盤空間，但是會消耗一些CPU的計算時間，默認開啟
rdbchecksum	使用CRC64演算法來進行資料校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能，

如果需要關閉RDB的持久化機制，可以參考如下配置，開啟save，并注釋其他規則即可

save ""
#save 900 1
#save 300 10
#save 60 10000

用戶執行SAVE或者GBSAVE命令

除了讓Redis自動進行快照以外，當我們對服務進行重啟或者服務器遷移我們需要人工去干預備份，redis提供了兩條命令來完成這個任務

save命令

如圖4-24所示，當執行save命令時，Redis同步做快照操作，在快照執行程序中會阻塞所有來自客戶端的請求，當redis記憶體中的資料較多時，通過該命令將導致Redis較長時間的不回應，所以不建議在生產環境上使用這個命令，而是推薦使用bgsave命令

圖4-24
bgsave命令

如圖4-25所示，bgsave命令可以在后臺異步地進行快照操作，快照的同時服務器還可以繼續回應來自客戶端的請求，執行BGSAVE后，Redis會立即回傳ok表示開始執行快照操作，在redis-cli終端，通過下面這個命令可以獲取最近一次成功執行快照的時間（以 UNIX 時間戳格式表示），
```
LASTSAVE
```

1：redis使用fork函式復制一份當前行程的副本(子行程)

2：父行程繼續接收并處理客戶端發來的命令，而子行程開始將記憶體中的資料寫入硬碟中的臨時檔案

3：當子行程寫入完所有資料后會用該臨時檔案替換舊的RDB檔案，至此，一次快照操作完成，

注意：redis在進行快照的程序中不會修改RDB檔案，只有快照結束后才會將舊的檔案替換成新的，也就是說任何時候RDB檔案都是完整的，這就使得我們可以通過定時備份RDB檔案來實作redis資料庫的備份， RDB檔案是經過壓縮的二進制檔案，占用的空間會小于記憶體中的資料，更加利于傳輸，

bgsave是異步執行快照的，bgsave寫入的資料就是for行程時redis的資料狀態，一旦完成fork，后續執行的新的客戶端命令對資料產生的變更都不會反應到本次快照

Redis啟動后會讀取RDB快照檔案，并將資料從硬碟載入到記憶體，根據資料量大小以及服務器性能不同，這個載入的時間也不同，

圖4-25

執行FLUSHALL命令

該命令在前面講過，會清除redis在記憶體中的所有資料，執行該命令后，只要redis中配置的快照規則不為空，

也就是save 的規則存在，redis就會執行一次快照操作，不管規則是什么樣的都會執行，如果沒有定義快照規則，就不會執行快照操作，

執行復制(replication)時

該操作主要是在主從模式下，redis會在復制初始化時進行自動快照，這個會在后面講到；

這里只需要了解當執行復制操作時，即時沒有定義自動快照規則，并且沒有手動執行過快照操作，它仍然會生成RDB快照檔案，

RDB資料恢復演示

準備初始資料

  redis> set k1 1
  redis> set k2 2
  redis> set k3 3
  redis> set k4 4
  redis> set k5 5

通過shutdown命令關閉觸發save
```
redis> shutdown
```
備份dump.rdb檔案(用來后續恢復)
```
cp dump.rdb dump.rdb.bak
```
接著再啟動redis-server(systemctl restart redis_6379)，通過keys命令查看，發現資料還在
```
keys *
```

模擬資料丟失

執行flushall
```
redis> flushall
```
shutdown(重新生成沒有資料的快照，用來模擬后續的資料恢復)
```
redis> shutdown
```
再次啟動redis, 通過keys 命令查看，此時rdb中沒有任何資料，
恢復之前備份的rdb檔案（之前保存了資料的rdb快照）
```
mv dump.rdb.bak dump.rdb
```
再次重啟redis，可以看到之前快照保存的資料
```
keys *
```

檔案的優勢和劣勢

一、優勢

　　1.RDB是一個非常緊湊(compact)的檔案，它保存了redis 在某個時間點上的資料集，這種檔案非常適合用于進行備份和災難恢復，

　　2.生成RDB檔案的時候，redis主行程會fork()一個子行程來處理所有保存作業，主行程不需要進行任何磁盤IO操作，

　　3.RDB 在恢復大資料集時的速度比AOF的恢復速度要快，

二、劣勢

1、RDB方式資料沒辦法做到實時持久化/秒級持久化，因為bgsave每次運行都要執行fork操作創建子行程，頻繁執行成本過高
2、在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照之后的所有修改（資料有丟失），

如果資料相對來說比較重要，希望將損失降到最小，則可以使用AOF方式進行持久化，

AOF模式

AOF(Append Only File)：Redis 默認不開啟，AOF采用日志的形式來記錄每個寫操作，并追加到檔案中，開啟后，執行更改Redis資料的命令時，就會把命令寫入到AOF檔案中，

Redis 重啟時會根據日志檔案的內容把寫指令從前到后執行一次以完成資料的恢復作業，

AOF配置開關

# 開關
appendonly no  /yes
# 檔案名
appendfilename "appendonly.aof"

通過修改redis.conf重啟redis之后：systemctl restart redis_6379，

再次運行redis的相關操作命令，會發現在指定的dir目錄下生成appendonly.aof檔案，通過vim查看該檔案內容如下

*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$3
mic
*3
$3
set
$4
name
$3
123

AOF配置相關問題解答

問題1：資料都是實時持久化到磁盤嗎？

雖然每次執行更改Redis資料庫內容的操作時，AOF都會將命令記錄在AOF檔案中，但是事實上，由于作業系統的快取機制，資料并沒有真正地寫入硬碟，而是進入了系統的硬碟快取，在默認情況下系統每30秒會執行一次同步操作，以便將硬碟快取中的內容真正地寫入硬碟，

在這30秒的程序中如果系統例外退出則會導致硬碟快取中的資料丟失，一般來說能夠啟用AOF的前提是業務場景不能容忍這樣的資料損失，這個時候就需要Redis在寫入AOF檔案后主動要求系統將快取內容同步到硬碟中，在redis.conf中通過如下配置來設定同步機制，

引數	說明
appendfsync everysec	AOF持久化策略（硬碟快取到磁盤），默認everysec 1 no 表示不執行fsync，由作業系統保證資料同步到磁盤，速度最快，但是不太安全； 2 always 表示每次寫入都執行fsync，以保證資料同步到磁盤，效率很低； 3 everysec表示每秒執行一次fsync，可能會導致丟失這1s資料，通常選擇 everysec ，兼顧安全性和效率，

問題2：檔案越來越大，怎么辦？

由于AOF持久化是Redis不斷將寫命令記錄到 AOF 檔案中，隨著Redis不斷的運行，AOF 的檔案會越來越大，檔案越大，占用服務器記憶體越大以及 AOF 恢復要求時間越長，

例如set gupao 666，執行1000次，結果都是gupao=666，

為了解決這個問題，Redis新增了重寫機制，當AOF檔案的大小超過所設定的閾值時，Redis就會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集，

可以使用命令下面這個命令主動觸發重寫

redis> bgrewriteaof

AOF 檔案重寫并不是對原檔案進行重新整理，而是直接讀取服務器現有的鍵值對，然后用一條命令去代替之前記錄這個鍵值對的多條命令，生成一個新的檔案后去替換原來的 AOF 檔案，

重寫觸發機制如下

引數	說明
auto-aof-rewrite-percentage	默認值為100，表示的是當目前的AOF檔案大小超過上一次重寫時的AOF檔案大小的百分之多少時會再次進行重寫，如果之前沒有重寫過，則以啟動時AOF檔案大小為依據
auto-aof-rewrite-min-size	默認64M，表示限制了允許重寫的最小AOF檔案大小，通常在AOF檔案很小的情況下即使其中有很多冗余的命令我們也并不太關心

在啟動時，Redis會逐個執行AOF檔案中的命令來將硬碟中的資料載入到記憶體中，載入的速度相對于RDB會慢一些

問題：重寫程序中，AOF檔案被更改了怎么辦？

Redis 可以在 AOF 檔案體積變得過大時，自動地在后臺對 AOF 進行重寫：重寫后的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合，

重寫的流程是這樣，

主行程會fork一個子行程出來進行AOF重寫，這個重寫程序并不是基于原有的aof檔案來做的，而是有點類似于快照的方式，全量遍歷記憶體中的資料，然后逐個序列到aof檔案中，
在fork子行程這個程序中，服務端仍然可以對外提供服務，那這個時候重寫的aof檔案的資料和redis記憶體資料不一致了怎么辦？不用擔心，這個程序中，主行程的資料更新操作，會快取到aof_rewrite_buf中，也就是單獨開辟一塊快取來存盤重寫期間收到的命令，當子行程重寫完以后再把快取中的資料追加到新的aof檔案，
當所有的資料全部追加到新的aof檔案中后，把新的aof檔案重命名正式的檔案名字，此后所有的操作都會被寫入新的aof檔案，
如果在rewrite程序中出現故障，不會影響原來aof檔案的正常作業，只有當rewrite完成后才會切換檔案，因此這個rewrite程序是比較可靠的，