一、基本介紹

我們知道對於一個企業級的redis架構來說，持久化是不可減少的。持久化主要是做災難恢復，數據恢復，也可以歸類到高可用的一個環節裏面去。比如你redis整個掛了，然後redis就不可用了，你要做的事情是讓redis變得可用，儘快變得可用。重啓redis，儘快讓它對外提供服務，但是就像上一講說，如果你沒做數據備份，這個時候redis啓動了，也不可用啊，數據都沒了。很可能說，大量的請求過來，緩存全部無法命中，在redis里根本找不到數據，這個時候就死定了，緩存雪崩問題，所有請求，沒有在redis命中，就會去mysql數據庫這種數據源頭中去找，一下子mysql承接高併發，然後就掛了。mysql掛掉，你都沒法去找數據恢復到redis裏面去，redis的數據從哪兒來？從mysql來。。。

如果你把redis的持久化做好，備份和恢復方案做到企業級的程度，那麼即使你的redis故障了，也可以通過備份數據，快速恢復，一旦恢復立即對外提供服務。

1、RDB持久化

RDB方式的持久化是通過快照（snapshotting）完成的，當符合一定條件時Redis會自動將內存中的數據進行快照並持久化到硬盤。RDB是Redis默認採用的持久化方式。Redis啓動後會讀取RDB快照文件，將數據從硬盤載入到內存。根據數據量大小與結構和服務器性能不同，這個時間也不同。通常將記錄一千萬個字符串類型鍵、大小爲1GB的快照文件載入到內存中需要花費20～30秒鐘。

1.持久化條件配置

在redis.conf中修改持久化快照的條件，如下：

說明：

save 開頭的一行就是持久化配置，可以配置多個條件（每行配置一個條件），每個條件之間是“或”的關係。
“save 900 1”表示15分鐘（900秒鐘）內至少1個鍵被更改則進行快照。
“save 300 10”表示5分鐘（300秒）內至少10個鍵被更改則進行快照。
也可以手動調用save或者bgsave命令，同步或異步執行rdb快照生成。

2.持久化文件存儲

在redis.conf中可以指定持久化文件存儲的目錄

配置dir指定rdb快照文件的位置；
設置dbfilename指定rdb快照文件的名稱；

在執行RDB持久化工作時，redis根據配置自己fork一個子進程出來，子進程嘗試將數據dump到臨時的rdb快照文件中，完成rdb快照文件的生成之後，就替換之前的舊的快照文件。即每次生成一個新的快照，都會覆蓋之前的老快照。

3.優缺點分析

優點：

RDB會生成多個數據文件，每個數據文件都代表了某一個時刻完整的數據快照，這種多個數據文件的方式，非常適合做冷備，可以將這種完整的數據文件發送到一些遠程的安全存儲上去，比如說Amazon的S3雲服務上去，在國內可以是阿里雲的ODPS分佈式存儲上，以預定好的備份策略來定期備份redis中的數據。當然AOF也可以做冷備，只有一個文件，但是你可以，每隔一定時間，去copy一份這個文件出來，比較麻煩。
RDB對redis對外提供的讀寫服務，影響非常小，可以讓redis保持高性能，因爲redis主進程只需要fork一個子進程，讓子進程執行磁盤IO操作來進行RDB持久化即可
相對於AOF持久化機制來說，直接基於RDB數據文件來重啓和恢復redis進程，更加快速。AOF，存放的指令日誌，做數據恢復的時候，其實是要回放和執行所有的指令日誌，來恢復出來內存中的所有數據的。RDB，就是一份數據文件，恢復的時候，直接加載到內存中即可。

結合上述優點，RDB特別適合做冷備份，冷備。

缺點：

如果想要在redis故障時，儘可能少的丟失數據，那麼RDB沒有AOF好。一般來說，RDB數據快照文件，都是每隔5分鐘，或者更長時間生成一次，這個時候就得接受一旦redis進程宕機，那麼會丟失最近5分鐘的數據。這個問題，也是rdb最大的缺點，就是不適合做第一優先的恢復方案，如果你依賴RDB做第一優先恢復方案，會導致數據丟失的比較多。
RDB每次在fork子進程來執行RDB快照數據文件生成的時候，如果數據文件特別大，可能會導致對客戶端提供的服務暫停數毫秒，或者甚至數秒。一般不要讓RDB的間隔太長，否則每次生成的RDB文件太大了，對redis本身的性能可能會有影響的。

4.數據實驗

我們首先在redis中保存幾條數據

[root@redis_01 bin]# ./redis-cli
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> exit

立即停掉redis進程，然後重啓redis

[root@redis_01 bin]# ./redis-cli SHUTDOWN
[root@redis_01 bin]# ps -ef | grep redis
root      11101  10813  0 11:02 pts/0    00:00:00 grep --color=auto redis
[root@redis_01 bin]# /etc/init.d/./redis_6379 start
Starting Redis server...

下面我們看看剛纔插入的數據還在不在

127.0.0.1:6379> get k1
"v1"

數據還在，爲什麼？這裏要注意，通過redis-cli SHUTDOWN這種方式去停掉redis，其實是一種安全退出的模式，redis在退出的時候會將內存中的數據立即生成一份完整的rdb快照。我們可以看一下（不能直接看懂）

[root@redis_01 bin]# cat /var/redis/6379/dump.rdb 
REDIS0007   redis-ver3.2.8
þ?v2k3v3k1v1kkvvÿ8,ޞl

在redis中再保存幾條新的數據，用kill -9粗暴殺死redis進程，模擬redis故障異常退出，導致內存數據丟失的場景

127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379> exit
[root@redis_01 bin]# ps -ef|grep redis
root      11131      1  0 11:04 ?        00:00:00 /usr/local/software/redis/bin/redis-server 127.0.0.1:6379
root      11150  10813  0 11:09 pts/0    00:00:00 grep --color=auto redis
[root@redis_01 bin]# kill -9 11131

然後我們再來重啓redis服務器

[root@redis_01 bin]# /etc/init.d/./redis_6379 start
/var/run/redis_6379.pid exists, process is already running or crashed
[root@redis_01 bin]# rm -rf /var/run/redis_6379.pid 
[root@redis_01 bin]# /etc/init.d/./redis_6379 start
Starting Redis server...

這次就發現，redis進程異常被殺掉，數據沒有進dump文件，幾條最新的數據就丟失了

[root@redis_01 bin]# ./redis-cli
127.0.0.1:6379> get k4
(nil)
127.0.0.1:6379> get k5
(nil)
127.0.0.1:6379> get k3
"v3"

現在我們手動設置一個save檢查點（記得重啓一下生效，試驗完記得註釋掉，太頻繁了）

寫入幾條數據，等待5秒鐘，會發現自動進行了一次dump rdb快照，在dump.rdb中發現了數據

127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379> exit
[root@redis_01 bin]# cat /var/redis/6379/dump.rdb
REDIS0007   redis-ver3.2.8
redis-bits????e5used-mem0
                       ??k5v5k3v3kkvvk4v4k1v1k2v2??7????

2、AOF持久化

1.持久化條件配置

Redis默認是不使用該方式持久化的。Aof方式的持久化，是操作一次redis數據庫，則將操作的記錄（日誌）存儲到aof持久化文件中。如果我們要開啓aof方式的持久化方案，需要將redis.conf中的appendonly改爲yes。

在生產環境裏面，一般來說AOF都是要打開的，除非你說隨便丟個幾分鐘的數據也無所謂。其中AOF文件存放的是每條寫命令，所以會不斷的膨脹，當大到一定的時候，AOF做rewrite操作。AOF 的rewrite操作就會基於當時redis內存中的數據重新構造一個更小的AOF文件，然後將舊的膨脹的很大的文件給刪除了。這裏注意一點，AOF並不是一點數據都不會丟失。在現代操作系統中，寫文件並不是直接寫入磁盤，而是先寫入os cache，然後到一定時間再從os cache執行fsync寫到磁盤文件。

這樣在redis重啓的時候，就可以通過回放AOF日誌中的寫入指令來重新構建整個數據集了。可以配置AOF的fsync策略，有三種策略可以選擇，一種是每次寫入一條數據就執行一次fsync；一種是每隔一秒執行一次fsync；一種是不主動執行fsync。

always：每次寫入一條數據，立即將這個數據對應的寫日誌fsync到磁盤上去，性能非常非常差，吞吐量很低; 確保說redis裏的數據一條都不丟，那就只能這樣了（mysql中由於需要大量磁盤操作，單機情況下QPS一般一兩k。對於redis來說，上萬QPS沒問題，但設置成always也就和mysql差不多了）；
everysec：每秒將os cache中的數據fsync到磁盤，這個最常用的，生產環境一般都這麼配置，性能很高，QPS還是可以上萬的；
no: 僅僅redis負責將數據寫入os cache就撒手不管了，然後後面os自己會時不時有自己的策略將數據刷入磁盤，不可控了。

2.持久化文件存儲

Aof文件存儲的目錄和rdb方式的一樣。Aof文件存儲的名稱爲：

我們知道redis中的數據其實有限的，很多數據可能會自動過期，可能會被用戶刪除，可能會被redis用緩存清除的算法清理掉。redis中的數據會不斷淘汰掉舊的，就一部分常用的數據會被自動保留在redis內存中。所以可能很多之前的已經被清理掉的數據，對應的寫日誌還停留在AOF中，AOF日誌文件就一個，會不斷的膨脹，到很大很大。

所以AOF會自動在後臺每隔一定時間做rewrite操作，比如日誌裏已經存放了針對100w數據的寫日誌了；redis內存只剩下10萬；基於內存中當前的10萬數據構建一套最新的日誌，到AOF中，覆蓋之前的老日誌，確保AOF日誌文件不會過大，保持跟redis內存數據量一致。在redis.conf中，可以配置rewrite策略：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

說明：比如說上一次AOF rewrite之後，是128mb；然後就會接着128mb繼續寫AOF的日誌，如果發現增長的比例，超過了之前的100%，256mb，就可能會去觸發一次rewrite；但是此時還要去跟min-size，64mb去比較，256mb > 64mb，纔會去觸發rewrite。

3.AOF的rewrite過程

redis fork一個子進程
子進程基於當前內存中的數據，構建日誌，開始往一個新的臨時的AOF文件中寫入日誌
redis主進程，接收到client新的寫操作之後，在內存中寫入日誌，同時新的日誌也繼續寫入舊的AOF文件
子進程寫完新的日誌文件之後，redis主進程將內存中的新日誌再次追加到新的AOF文件中
用新的日誌文件替換掉舊的日誌文件

注意：redis 2.4之前，還需要手動，開發一些腳本，crontab，通過BGREWRITEAOF命令去執行AOF rewrite，但是redis 2.4之後，會自動進行rewrite操作。

4.優缺點分析

優點：

AOF可以更好的保護數據不丟失，一般AOF會每隔1秒，通過一個後臺線程執行一次fsync操作，最多丟失1秒鐘的數據。每隔1秒，就執行一次fsync操作，保證os cache中的數據寫入磁盤中。
AOF日誌文件以append-only模式寫入，所以沒有任何磁盤尋址的開銷，寫入性能非常高，而且文件不容易破損，即使文件尾部破損，也很容易修復。
AOF日誌文件即使過大的時候，出現後臺重寫操作，也不會影響客戶端的讀寫。因爲在rewrite log的時候，會對其中的指令進行壓縮，創建出一份需要恢復數據的最小日誌出來。在創建新日誌文件的時候，老的日誌文件還是照常寫入。當新的merge後的日誌文件ready的時候，再交換新老日誌文件即可。
AOF日誌文件的命令通過非常可讀的方式進行記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有數據，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝AOF文件，將最後一條flushall命令給刪了，然後再將該AOF文件放回去，就可以通過恢復機制，自動恢復所有數據。

缺點：

對於同一份數據來說，AOF日誌文件通常比RDB數據快照文件更大。
AOF開啓後，支持的寫QPS會比RDB支持的寫QPS低，因爲AOF一般會配置成每秒fsync一次日誌文件，當然，每秒一次fsync，性能也還是很高的。如果你要保證一條數據都不丟，也是可以的，AOF的fsync設置成每寫入一條數據，fsync一次，那就完蛋了，redis的QPS大降。
以前AOF發生過bug，就是通過AOF記錄的日誌，進行數據恢復的時候，沒有恢復一模一樣的數據出來。所以說，類似AOF這種較爲複雜的基於命令日誌/merge/回放的方式，比基於RDB每次持久化一份完整的數據快照文件的方式，更加脆弱一些，容易有bug。不過AOF就是爲了避免rewrite過程導致的bug，因此每次rewrite並不是基於舊的指令日誌進行merge的，而是基於當時內存中的數據進行指令的重新構建，這樣健壯性會好很多。
唯一的比較大的缺點，其實就是做數據恢復的時候，會比較慢，還有做冷備，定期的備份，不太方便，可能要自己手寫複雜的腳本去做，做冷備不太合適。

5.數據實驗

我們在上面實驗發現先僅僅打開RDB，寫入一些數據，然後kill -9殺掉redis進程，接着重啓redis，發現數據沒了，因爲RDB快照還沒生成。現在我們打開AOF的開關，啓用AOF持久化。然後再寫入一些數據，觀察AOF文件中的日誌內容

[root@redis_01 bin]# cat /var/redis/6379/appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$2
k1
$2
v1
*3
$3
set
$2
k2
$2
v2

其實你在appendonly.aof文件中，可以看到剛寫的日誌，它們其實就是先寫入os cache的，然後1秒後才fsync到磁盤中，只有fsync到磁盤中了，纔是安全的，要不然光是在os cache中，機器只要重啓，就什麼都沒了。kill -9殺掉redis進程，重新啓動redis進程，發現數據被恢復回來了，就是從AOF文件中恢復回來的。

如果redis在append數據到AOF文件時，機器宕機了，可能會導致AOF文件破損。用redis-check-aof --fix命令來修復破損的AOF文件，比如現在我們把最後兩行刪了，然後執行恢復

[root@redis_01 src]# pwd
/usr/local/software/redis-3.2.8/src
[root@redis_01 src]# ./redis-check-aof --fix /var/redis/6379/appendonly.aof 
AOF analyzed: size=102, ok_up_to=81, diff=21
This will shrink the AOF from 102 bytes, with 21 bytes, to 81 bytes
Continue? [y/N]: y
Successfully truncated AOF

二、企業級的持久化的配置策略

在企業中不要僅僅使用RDB，因爲那樣會導致你丟失很多數據。也不要僅僅使用AOF，因爲那樣有兩個問題，第一，你通過AOF做冷備，沒有RDB做冷備，來的恢復速度更快；第二，RDB每次簡單粗暴生成數據快照，更加健壯，可以避免AOF這種複雜的備份和恢復機制的bug。

綜合使用AOF和RDB兩種持久化機制，用AOF來保證數據不丟失，作爲數據恢復的第一選擇；用RDB來做不同程度的冷備，在AOF文件都丟失或損壞不可用的時候，還可以使用RDB來進行快速的數據恢復。

如果RDB在執行snapshotting操作，那麼redis不會執行AOF rewrite；如果redis再執行AOF rewrite，那麼就不會執行RDB snapshotting。如果RDB在執行snapshotting，此時用戶執行BGREWRITEAOF命令，那麼等RDB快照生成之後，纔會去執行AOF rewrite。

同時有RDB snapshot文件和AOF日誌文件，那麼redis重啓的時候，會優先使用AOF進行數據恢復，因爲其中的日誌更完整。

1、RDB的生成策略

在企業中，RDB的生成策略，用默認的也差不多

save 60 10000

如果你希望儘可能確保說，RDB最多丟1分鐘的數據，那麼儘量就是每隔1分鐘都生成一個快照。不過到底是10000條執行一次RDB，還是1000條執行一次RDB，這個根據需要根據自己的應用和業務的數據量來確定。

2、AOF的生成策略

AOF一定要打開，fsync方式選擇everysec。一般可能會調整的參數可能就是下面倆參數了

auto-aof-rewrite-percentage 100

就是當前AOF大小膨脹到超過上次100%，上次的兩倍。

auto-aof-rewrite-min-size 64mb

根據自己的數據量來定，16mb，32mb。

三、企業級的數據備份方案

RDB非常適合做冷備，每次生成之後，就不會再有修改了。我們可以寫crontab定時調度腳本去做數據備份。每小時都copy一份rdb的備份，到一個目錄中去，僅僅保留最近48小時的備份

crontab -e

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

redis_rdb_copy_hourly.sh

#!/bin/sh 

cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date

每天都保留一份當日的rdb的備份，到一個目錄中去，僅僅保留最近1個月的備份

crontab -e

0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

redis_rdb_copy_daily.sh

redis_rdb_copy_daily.sh

#!/bin/sh 

cur_date=`date +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date

每次copy備份的時候，都把太舊的備份給刪了。最後每天晚上將當前服務器上所有的數據備份，發送一份到遠程的雲服務上去。

四、數據恢復方案

如果是redis進程掛掉，那麼重啓redis進程即可，直接基於AOF日誌文件恢復數據

這裏不演示了，在AOF數據恢復那一塊，演示過了，fsync everysec，最多就丟一秒的數。

如果是redis進程所在機器掛掉，那麼重啓機器後，嘗試重啓redis進程，嘗試直接基於AOF日誌文件進行數據恢復

AOF沒有破損，也是可以直接基於AOF恢復的。如果AOF文件破損，那麼用redis-check-aof fix。

如果redis當前最新的AOF和RDB文件出現了丟失/損壞，那麼可以嘗試基於該機器上當前的某個最新的RDB數據副本進行數據恢復

當前最新的AOF和RDB文件都出現了丟失/損壞到無法恢復，一般不是機器的故障，而是人爲造成的。比如我們把/var/redis/6379下的文件給刪除了，找到RDB最新的一份備份，小時級的備份可以了，小時級的肯定是最新的，copy到redis裏面去，就可以恢復到某一個小時的數據。

但是當我們拷貝到redis上重啓後發現沒有數據，因爲優先用appendonly.aof去恢復數據，我們發現redis自動生成的appendonly.aof是沒有數據的。redis啓動的時候，自動重新基於內存的數據，生成了一份最新的rdb快照，直接用空的數據，覆蓋掉了我們有數據的（拷貝過去的那份dump.rdb）。

然後再次停止redis，先刪除appendonly.aof，然後將我們的dump.rdb拷貝過去，然後再重啓redis，然後又沒有數據！很簡單，就是雖然你刪除了appendonly.aof，但是因爲打開了aof持久化，redis就一定會優先基於aof去恢復，即使文件不在，那就創建一個新的空的aof文件。

停止redis，暫時在配置中關閉aof，然後拷貝一份rdb過來，再重啓redis，數據能不能恢復過來，可以恢復過來。腦子一熱，再關掉redis，手動修改配置文件，打開aof，再重啓redis，數據又沒了，空的aof文件，所有數據又沒了！在數據安全丟失的情況下，基於rdb冷備，如何完美的恢復數據，同時還保持aof和rdb的雙開？

停止redis，關閉aof，拷貝rdb備份，重啓redis，確認數據恢復，直接在命令行熱修改redis配置，打開aof，這個redis就會將內存中的數據對應的日誌，寫入aof文件中。此時aof和rdb兩份數據文件的數據就同步了。

[root@redis_01 bin]# ./redis-cli config get appendonly
1) "appendonly"
2) "no"
[root@redis_01 bin]# ./redis-cli config set appendonly yes
OK

redis config set熱修改配置參數，可能配置文件中的實際的參數沒有被持久化的修改，再次停止redis，手動修改配置文件，打開aof的命令，再次重啓redis。

如果當前機器上的所有RDB文件全部損壞，那麼從遠程的雲服務上拉取最新的RDB快照回來恢復數據
如果是發現有重大的數據錯誤，比如某個小時上線的程序一下子將數據全部污染了，數據全錯了，那麼可以選擇某個更早的時間點，對數據進行恢復

舉個例子，12點上線了代碼，發現代碼有bug，導致代碼生成的所有的緩存數據，寫入redis，全部錯了。找到一份11點的rdb的冷備，然後按照上面的步驟，去恢復到11點的數據，就可以了。

redis系列——企業級持久化方案（四）

一、基本介紹

1、RDB持久化

1.持久化條件配置

2.持久化文件存儲

3.優缺點分析

4.數據實驗

2、AOF持久化

1.持久化條件配置

2.持久化文件存儲

3.AOF的rewrite過程

4.優缺點分析

5.數據實驗

二、企業級的持久化的配置策略

1、RDB的生成策略

2、AOF的生成策略

三、企業級的數據備份方案

四、數據恢復方案

[軟件工具百科] 互聯網資源歷史快照歸檔站點與數字圖書館

網易面試：SpringBoot如何開啓虛擬線程？

杭州的 IT 崩盤了麼？

程序員常見的文本查看工具

VS2022 解決方案打不開 .NET Framework 4.0 、 4.5 等老項目

Vue3 運行可以，build 打包發佈報錯，app.config.globalProperties 用法坑

既然測試也要求寫代碼，那乾脆讓開發兼任測試不就好了嗎？

ITSM落地經驗之建設藍圖規劃

PDF 補丁丁 1.0.2 版更新

奇怪！應用的日誌呢？？

docker教程——利用 commit 理解鏡像構成（五）

Spring Boot整理——Spring Boot項目採用Docker部署（十一）

Oracle——基本內容（一）

spring security——Spring Social簡介（五）

redis系列——企業級持久化方案（四）

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結