本文轉載自微信公眾號「零零后程序員小三」，作者003 。轉載本文請聯系零零后程序員小三公眾號。

 本文是對Redis6的持久化配置，了解什么是AOF和RDB，它們的優缺點是什么，該如何使用。

什么是Redis持久化?

我們都知道Redis是一個基于內存的數據庫，如果沒有給Redis配置持久化的話，每當重啟后Redis的數據就會全部丟失，會很麻煩。因此Redis需要開啟持久化功能，將數據保存到磁盤上，當Redis重啟后可以在磁盤中恢復數據。這樣緩存數據就不容易丟失了。

開啟持久化的兩種方式

Redis開啟持久化有兩種方式：RDB(Redis DataBase)與AOF(append only file)

RDB持久化

RDB其實就是把數據以快照的形式保存到磁盤上。什么是快照呢?你可以把快照理解成當前這一時刻的數據拍成一張照片保存下來。RDB持久化是指在指定的時間間隔內將內存中的數據集快照形式寫入磁盤。也是默認的持久化方式，這種方式就是將內存中的數據寫入到二進制文件當中，默認的文件名為dump.rdb

既然RDB機制是通過某個時刻把所有數據生成一張快照來進行保存的，那么就應該會有一種觸發機制來實現這個過程。對于RDB來說，提供了三種機制：save、bgsave、自動化。

1.save觸發方式：該命令會阻塞當前Redis服務器，執行save命令的時候，Redis不能處理其他的命令，直到RDB過程執行完成為止。執行完成的時候如果存在老的RDB文件，就會把新的替換掉舊的。

2.bgsave觸發方式：執行該命令的時候，Redis會在后臺進行異步快照操作，快照的同時還可以響應客戶端的請求，具體的操作是Redis進程執行fork操作創建了一個子進程，而RDB持久化過程由子進程負載，完成后自動結束。阻塞只發生在子進程。

3.自動化觸發：由配置文件來完成，配置觸發Redis的RDB持久化條件。

「RDB有何優缺點?」

優點：

(1)RDB文件緊湊，全量備份，比較適用于備份和災難恢復

(2)生成RDB文件的時候，Redis主進程會開啟讓一個子進程來完成所有的保存操作，主進程不需要任何的IO操作

(3)RDB在恢復大數據集的時候速度快。

缺點：

因為RDB快照是一次全量備份的，存儲的是內存數據二進制形式，在存儲上會非常的緊湊。當進行快照持久化時，會開啟一個子進程負載快照的持久化，子進程會擁有父進程的內存數據，父進程修改內存子進程不會反應出來，所有當在快照持久化時修改的數據不會得以保存，還有可能導致丟失數據。

核心配置：(dbfilename 文件名，dir持久化文件的路徑)

#任何ip可以訪問 
bind 0.0.0.0 
#守護進程 
daemonize yes 
#密碼 
requirepass 123456 
#⽇志⽂件 
logfile "/usr/local/redis/log/redis.log" 
#持久化⽂件名稱 
dbfilename xdclass.rdb 
#持久化⽂件存儲路徑 
dir /usr/local/redis/data 
#持久化策略, 10秒內有個1個key改動，執⾏快照 
save 10 1 
######之前配置###### 
#導出rdb數據庫⽂件壓縮字符串和對象,默認是yes，會浪費 
CPU但是節省空間 
rdbcompression yes 
# 導⼊時是否檢查 
rdbchecksum yes 

RDB操作實戰

配置文件(根據自行需要配置)

bind 0.0.0.0 
daemonize yes 
requirepass 123456Xdclass 
logfile "/usr/local/redis/log/redis.log" 
dbfilename xdclass.rdb 
dir /usr/local/redis/data 
#關閉rdb 
#save "" 
#10秒2個key變動則觸發rdb 
save 10 2 
#100秒5個key變動則觸發rdb 
save 100 5 
#壓縮 
rdbcompression yes 
#檢查 
rdbchecksum yes 

備注：Linux內存分配策略，0表示內核將檢查是否有足夠的內存供應用進程所使用;如果有足夠內存則申請允許;否則申請失敗，并發錯誤返回給應用進程

1表示內核允許分配所有的物理內存，而不管當前的內存狀態如何

2表示內核允許分配超過所有物理內存和交換總和內存

解決⽅式 
echo 1 > /proc/sys/vm/overcommit_memory 
 
持久化配置 
vim /etc/sysctl.conf 
 
改為 
vm.overcommit_memory=1 
修改sysctl.conf后，需要執⾏ sysctl -p 以使⽣效。 

AOF持久化

上面介紹了RDB持久化是全量備份的，但這種備份總是耗時的，有時候我們提供了一種更為高效的方式AOF，工作機制很簡單，Redis會將每一個收到的命令都通過write函數追加到文件中。通俗點理解就是像日志記錄一樣。

配置：

與RDB配置方式不一樣

appendonly yes 默認為不開啟 
AOF文件名通過appendfilename配置設置，默認文件名為appendonly.aof 
存儲路徑同RDB持久化方式一致，使用dir配置 

bind 0.0.0.0 
daemonize yes 
requirepass 123456Xdclass 
logfile "/usr/local/redis/log/redis.log" 
dbfilename xdclass.rdb 
dir /usr/local/redis/data 
#save 10 2 
#save 100 5 
save "" 
rdbcompression yes 
#對rdb數據進⾏校驗，耗費CPU資源，默認為yes 
rdbchecksum yes 
appendonly yes 
appendfilename "appendonly.aof" 
appendfsync everysec 

AOF核心原理

(1)Redis每次寫入命令會追加到aof_buf緩沖區中

(2)AOF緩沖區根據對應的策略向硬盤做同步的操作

(3)高頻AOF會帶來影響，特別是每次刷盤

AOF三種觸發機制

(1)每修改同步always：同步持久化 每次發送數據更變會立即被記錄到磁盤中，性能較差但是數據保存的完整性比較好

(2)每秒同步everysec：異步操作，每秒記錄，如果一秒內宕機的話，會造成數據丟失。

(3)不同no：從不同步

AOF有何優缺點?

優點：

(1)AOF可以更好的對數據保護，不讓數據丟失。一般AOF會每隔一秒，通過后臺線程執行一次fsync操作，最多丟失一秒鐘的數據

(2)AOF日志文件沒有任何磁盤尋址的開銷，寫入性能非常高，文件也不容易損壞。

(3)AOF日志文件的命令擁有很好的可讀方式進行記錄，因為這個特征非常適合做災難性的誤刪除恢復。

缺點：

(1)對于同一份數據來說的話，AOF文件的日志通常要比RDB數據快照文件要更大。

(2)AOF開啟后，支持的寫QPS會比RDB支持的寫QPS低，因為AOF一般配置成每秒fsync一次日志文件。

AOF配置實戰

「文件重新原理」

AOF的方式也同時帶來了另一個問題。持久化文件會變得越來越大，為了壓縮aof持久化文件。Redis提供了一個barewriteaof命令。來講內存中的數據以命令的形式保存到臨時文件中，同時會開啟一條新進程來重寫，重寫aof文件的操作，并沒有讀取舊的aof文件，而是把整個內存中的數據庫內容用命令的形式重寫了一個新的aof文件，這個和快照有點類似。

重寫觸發配置

手動觸發：直接調用bgrewriteaof命令

自動觸發：auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(auto-aof-rewrite-min-size表示AOF重寫文件最小體積，默認為64MB;auto-aof-rewrite-percentage代表AOF文件空間和上一次重寫后AOF文件空間的比值)

常用配置

# 是否開啟aof 
appendonly yes 
# ⽂件名稱 
appendfilename "appendonly.aof" 
# 同步⽅式 
appendfsync everysec 
# aof重寫期間是否同步 
no-appendfsync-on-rewrite no 
# 重寫觸發配置 
auto-aof-rewrite-percentage 100 
auto-aof-rewrite-min-size 64mb 
# 加載aof時如果有錯如何處理 
# yes表示如果aof尾部⽂件出問題，寫log記錄并繼續執⾏。 
no表示提示寫⼊等待修復后寫⼊ 
aof-load-truncated yes 

在線上，我們到底該怎么做?

(1)RDB持久化與AOF持久化起使

(2)如果Redis中的數據并不是特別敏感或者可以通過其它?式重寫?成數據

(3)集群中可以關閉AOF持久化，靠集群的備份?式保證可?性

(4)??制定策略定期檢查Redis的情況，然后可以?動觸發備份、重寫數據;

(5)采?集群和主從同步

在Redis4.0后支持混合模式

RDB和AOF可以一起用了，直接將RDB持久化的方式來操作二進制內容覆蓋到AOF文件中，因為RDB是二進制，所以很小。有寫入的話還是繼續append追加到文件的原始命令，等下次文件過大的時候在次rewrite，所以在企業中這種混合模式是比較常見的。