對長期奮戰在一線的后端開發人員來說，都知道redis有兩種持久化方式RDB和AOF，雖說大家都知道這兩種方式大概運作方式，但想必有實操的人不會太多。
這里是自己實操兩種持久化方式的一點點記錄。
先看以下摘錄自redis官網原文解釋(原文是English，這里用google翻譯。)
Redis持久性
Redis提供了不同的持久性選項范圍：
RDB持久性按指定的時間間隔執行數據集的時間點快照。
AOF持久性會記錄服務器接收的每個寫入操作，這些操作將在服務器啟動時再次播放，以重建原始數據集。 使用與Redis協議本身相同的格式記錄命令，並且僅采用追加方式。 當日志太大時，Redis可以在后台重寫日志。
如果希望，只要您的數據在服務器運行時就一直存在，則可以完全禁用持久性。
可以在同一實例中同時合並AOF和RDB。 請注意，在這種情況下，當Redis重新啟動時，AOF文件將用於重建原始數據集，因為它可以保證是最完整的。
要理解的最重要的事情是RDB與AOF持久性之間的不同權衡。 讓我們從RDB開始：
RDB的優勢
RDB是Redis數據的非常緊湊的單文件時間點表示。 RDB文件非常適合備份。 例如，您可能希望在最近的24小時內每小時存檔一次RDB文件，並在30天之內每天保存一次RDB快照。 這使您可以在發生災難時輕松還原數據集的不同版本。
RDB對於災難恢復非常有用，它是一個緊湊的文件，可以傳輸到遠程數據中心或Amazon S3（可能已加密）上。
RDB最大限度地提高了Redis的性能，因為Redis父進程為了持久化所需要做的唯一工作就是分叉一個孩子，其余的都將做。 父實例將永遠不會執行磁盤I / O或類似操作。
與AOF相比，RDB允許大型數據集更快地重啟。
RDB的缺點
如果您需要在Redis停止工作（例如斷電后）的情況下最大程度地減少數據丟失的機會，則RDB不好。 您可以在生成RDB的位置配置不同的保存點 （例如，在至少五分鍾之后，對數據集進行100次寫入，但是您可以有多個保存點）。
但是，通常會每隔五分鍾或更長時間創建一次RDB快照，因此，如果Redis出於任何原因在沒有正確 關閉的情況下停止工作，則應該准備丟失最新的數據分鍾。
RDB需要經常使用fork（）才能使用子進程將其持久化在磁盤上。 如果數據集很大，Fork（）可能很耗時，並且如果數據集很大且CPU性能不佳，則可能導致Redis停止為客戶端服務幾毫秒甚至一秒鍾。 AOF還需要fork（），但您可以調整要重寫日志的頻率，而無需在持久性上進行權衡。
AOF的優勢
使用AOF Redis更加持久：您可以有不同的fsync策略：完全沒有fsync，每秒fsync，每個查詢fsync。 使用默認策略fsync時，每秒的寫入性能仍然很好（fsync是使用后台線程執行的，並且在沒有進行fsync的情況下，主線程將盡力執行寫入操作。）但是您只能損失一秒鍾的寫入時間。
AOF日志僅是一個追加日志，因此，如果斷電，也不會出現尋道或損壞問題。 即使由於某種原因（磁盤已滿或其他原因）以半寫命令結束日志，redis-check-aof工具也可以輕松修復它。
Redis太大時，Redis可以在后台自動重寫AOF。 重寫是完全安全的，因為Redis繼續追加到舊文件時，會生成一個全新的文件，其中包含創建當前數據集所需的最少操作集，一旦准備好第二個文件，Redis會切換這兩個文件並開始追加到新的那一個。
AOF以易於理解和解析的格式包含所有操作的日志。 您甚至可以輕松導出AOF文件。 例如，即使您使用FLUSHALL命令刷新了所有錯誤文件 ，如果在此期間未執行任何日志重寫操作，您仍然可以保存數據集，只是停止服務器，刪除最新命令並重新啟動Redis。
AOF的缺點
對於相同的數據集，AOF文件通常大於等效的RDB文件。
根據確切的fsync策略，AOF可能比RDB慢。 通常，在將fsync設置為每秒的情況下，性能仍然很高，並且在禁用fsync的情況下，即使在高負載下，它也應與RDB一樣快。 即使在巨大的寫負載情況下，RDB仍然能夠提供有關最大延遲的更多保證。
過去，我們在特定命令中遇到過罕見的錯誤（例如，其中有一個涉及阻塞命令，例如BRPOPLPUSH ）,導致生成的AOF在重載時無法重現完全相同的數據集。
這些錯誤很少見，我們在測試套件中進行了測試，自動創建了隨機的復雜數據集，然后重新加載它們以檢查一切是否正常。 但是，RDB持久性幾乎是不可能的。 更明確地說：Redis AOF通過增量更新現有狀態來工作，就像MySQL或MongoDB一樣，而RDB快照一次又一次地創建所有內容，從概念上講更健壯。
但是 1）應該注意的是，每次Redis重寫AOF時，都會從數據集中包含的實際數據開始從頭開始重新創建AOF，與始終附加AOF文件相比（或重寫后的讀數），對錯誤的抵抗力更強舊的AOF，而不是讀取內存中的數據）。
2）我們從未收到過有關真實環境中檢測到的AOF損壞的用戶報告。
以上所述就是RDB會根據配置文件的配置信息定時全量備份時間點的數據; AOF則是根據同步策略追加寫入備份文件。
一. RDB快照持久化
#首先我們看下配置文件的信息 [root@guangzhou data]# systemctl status redis ● redis.service - Redis 6379 Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled) Active: active (running) since 六 2020-01-18 16:26:42 CST; 18h ago Process: 344 ExecStop=/usr/local/redis/bin/redis-cli -h 127.0.0.1 -p 6379 -a jcon shutdown (code=exited, status=0/SUCCESS) Process: 348 ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf (code=exited, status=0/SUCCESS) Main PID: 349 (redis-server) CGroup: /system.slice/redis.service └─349 /usr/local/redis/bin/redis-server *:6379 1月 18 16:26:42 guangzhou systemd[1]: Starting Redis 6379... 1月 18 16:26:42 guangzhou systemd[1]: Started Redis 6379. #更改/usr/local/redis/etc/redis.conf中配置 #10秒鍾內2次更改寫入RDB二進制文件 save 10 2 # RDB持久化文件名 dbfilename dump.rdb # 數據持久化文件存儲目錄 dir /usr/local/redis/data # bgsave發生錯誤時是否停止寫入，通常為yes stop-writes-on-bgsave-error yes # rdb文件是否使用壓縮格式 rdbcompression yes # 是否對rdb文件進行校驗和檢驗，通常為yes rdbchecksum yes
#重啟redis
[root@guangzhou data]# systemctl restart redis
#為便於觀察先把redis數據清空，生產環境請慎重.
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> keys *
(empty list or set)
#操作前清空RDB文件
[root@guangzhou data]# pwd && ll
/usr/local/redis/data
總用量 0
#set兩條數據
127.0.0.1:6379> set a 100
OK
127.0.0.1:6379> set b 200
OK
#重命名RDB文件
[root@guangzhou data]# pwd && mv dump.rdb dump.rdb2 && ll
/usr/local/redis/data
總用量 4
-rw-r--r-- 1 root root 108 1月 19 15:42 dump.rdb2
#再次set兩條數據
127.0.0.1:6379> set c 300
OK
127.0.0.1:6379> set d 400
OK
#查看RDB文件,可以發現新的dump.rdb文件大於dump.rdb2,因為RDB是全量備份,dump.rdb比dump.rdb2多了key=c和key=d
[root@guangzhou data]# ll
總用量 8
-rw-r--r-- 1 root root 120 1月 19 16:59 dump.rdb
-rw-r--r-- 1 root root 108 1月 19 15:42 dump.rdb2
#現在我們將文件重命名
[root@guangzhou data]# pwd && mv dump.rdb dump.rdb3 && ll
/usr/local/redis/data
總用量 8
-rw-r--r-- 1 root root 108 1月 19 15:42 dump.rdb2
-rw-r--r-- 1 root root 120 1月 19 16:59 dump.rdb3
#清空數據
127.0.0.1:6379> flushdb
OK
#停止redis服務
[root@guangzhou data]# systemctl stop redis
#刪除最新生成的rdb文件，重命名僅含有key=a和key=b的dump.rdb2為dump.rdb
[root@guangzhou data]# pwd && rm -rf dump.rdb && mv dump.rdb2 dump.rdb && ll
/usr/local/redis/data
總用量 8
-rw-r--r-- 1 root root 108 1月 19 15:42 dump.rdb
-rw-r--r-- 1 root root 120 1月 19 16:59 dump.rdb3
#重啟redis服務(正常的話重啟后redis僅含有key=a和key=b兩個數據)
[root@guangzhou data]# systemctl restart redis
[root@guangzhou data]#
#重連redis列出所有key，果然如我們所料，只有a和b
127.0.0.1:6379> keys *
1) "a"
2) "b"
127.0.0.1:6379>
#如果對數據完整性要求較高，可以采用RDB快照，啟用定時任務備份指定時間點的數據文件，這樣一旦發生生產事故，可以很方便數據回滾；另外單個RDB二進制文件，方便文件分散存儲，數據遷移挪到其他服務器。
二. AOF方式持久化
#更改/usr/local/redis/etc/redis.conf中配置 #注釋上面RDB快照持久方式的配置，並更改aof配置 #開啟AOF日志追加 appendonly yes #日志追加的文件名 appendfilename "appendonly.aof" #寫入頻率，為了便於觀察，這里使用更新立即更新日志文件 appendfsync always #redis服務重啟 [root@guangzhou etc]# systemctl restart redis [root@guangzhou etc]# systemctl status redis ● redis.service - Redis 6379 Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled) Active: active (running) since 一 2020-01-20 15:40:17 CST; 9s ago Process: 5493 ExecStop=/usr/local/redis/bin/redis-cli -h 127.0.0.1 -p 6379 -a jcon shutdown (code=exited, status=0/SUCCESS) Process: 5497 ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf (code=exited, status=0/SUCCESS) Main PID: 5498 (redis-server) CGroup: /system.slice/redis.service └─5498 /usr/local/redis/bin/redis-server 127.0.0.1:6379 1月 20 15:40:17 guangzhou systemd[1]: Starting Redis 6379... 1月 20 15:40:17 guangzhou systemd[1]: Started Redis 6379. #轉到/usr/local/redis/data目錄，自動生成空文件,appendonly.aof [root@guangzhou data]# ll 總用量 0 -rw-r--r-- 1 root root 0 1月 20 15:42 appendonly.aof #命令行下錄入數據 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set a 1 OK 127.0.0.1:6379> set b 2 OK 127.0.0.1:6379> set c 3 OK 127.0.0.1:6379> #打印日志文件 [root@guangzhou data]# ll 總用量 8 -rw-r--r-- 1 root root 104 1月 20 15:43 appendonly.aof [root@guangzhou data]# cat appendonly.aof *2 $6 SELECT $1 0 *3 $3 set $1 a $1 1 *3 $3 set $1 b $1 2 *3 $3 set $1 c $1 3 #文件輸出可見每次操作詳情, #現在我們模擬異常情況,先重命名appendonly.aof文件為appendonly.aof2，停止redis服務 [root@guangzhou data]# pwd && mv appendonly.aof appendonly.aof2 && systemctl stop redis && rm -rf ./appendonly.aof && ll /usr/local/redis/data 總用量 8 -rw-r--r-- 1 root root 104 1月 20 15:43 appendonly.aof2 #在更改appendonly.aof2文件中c的數值為999, appendonly.aof2重命名為appendonly.aof，重啟redis服務 127.0.0.1:6379> keys * 1) "c" 2) "b" 3) "a" 127.0.0.1:6379> get c "993" #可見key=c的數據已改變 $3 set $1 c $3(更改時這里需要從1變為3) 993
生產環境我們可以RDB快照和AOF兩種方式結合起來使用，RDB快照文件可以定時備份
注意:
1) auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
意思啟用AOF時，redis會在AOF比上次完成重寫AOF時的容量大至少100%時開啟一個BGREWRITEAOF，並且AOF容量至少在64MB時發生;
2) 只配置 AOF ，重啟時加載 AOF 文件恢復數據
同時配置了 RDB 和 AOF ，啟動是只加載 AOF 文件恢復數據
只配置 RDB，啟動是將加載 dump 文件恢復數據
3) 命令行下save命令保存當前時間點全量數據快照, bgsave異步保存快照