概述

本文提供Redis持久化技術(shù)說(shuō)明, 建議所有Redis用戶閱讀. 如果您想更深入了解Redis持久性原理機(jī)制和底層持久性保證, 請(qǐng)參考文章 揭秘Redis持久化: http://antirez.com/post/redis-persistence-demystified.html

Redis持久化

Redis提供了不同級(jí)別的持久化選項(xiàng):

• RDB模式, Redis數(shù)據(jù)庫(kù)備份文件(Redis Database Backup)持久化方式, 提供周期性基于時(shí)間點(diǎn)的數(shù)據(jù)集快照備份, 比如每小時(shí)生成一個(gè)快照備份.
• AOF模式, 僅追加到文件(AppendOnlyFile)持久化方式, 在每次數(shù)據(jù)庫(kù)服務(wù)收到寫操作時(shí)記錄日志文件, 當(dāng)服務(wù)重啟時(shí), 自動(dòng)回放該日志來(lái)重建原始數(shù)據(jù)集. 日志中使用Redis自己的協(xié)議, 并按照統(tǒng)一的格式, 采用只追加的方法記錄. 當(dāng)日志文件太大時(shí), Redis可以在后臺(tái)重寫該日志, 生成一個(gè)最小化版本的日志文件.
• 你也可以完全禁用持久化, 比如只要保證服務(wù)在運(yùn)行中有數(shù)據(jù)或可以自動(dòng)生成緩存數(shù)據(jù)即可.
• 你還可以在同一個(gè)Redis實(shí)例上結(jié)合AOF和RDB兩種持久化方式. 請(qǐng)注意: 這種方式在Redis重啟時(shí), AOF文件會(huì)被用來(lái)重建原始數(shù)據(jù)集, 因?yàn)? 相對(duì)RDB周期快照的方式, AOF被認(rèn)為是更完整的數(shù)據(jù)備份, 比如它可以做到準(zhǔn)實(shí)時(shí)備份(只丟失1秒的數(shù)據(jù)).

接下來(lái), 讓我們來(lái)對(duì)比RDB和AOF的優(yōu)缺點(diǎn):

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

• RDB采用一個(gè)壓縮單文件來(lái)表示基于時(shí)間點(diǎn)的Redis數(shù)據(jù), RDB文件是完美的備份. 例如, 你可以保留過(guò)去24小時(shí)的每小時(shí)的快照備份, 并且保存過(guò)去30天, 每天的快照備份, 當(dāng)數(shù)據(jù)遇到丟失時(shí), 你可以很方便的從不同的備份粒度(版本)來(lái)恢復(fù)數(shù)據(jù)集.
• RDB用來(lái)做災(zāi)備恢復(fù)非常好, 因?yàn)榫o湊的單文件非常便于在遠(yuǎn)端數(shù)據(jù)中心或者亞馬遜S3(對(duì)象存儲(chǔ),可以加密)間傳輸.
• RDB使Redis性能最大化, 因?yàn)镽edis父進(jìn)程只需要啟動(dòng)一個(gè)子進(jìn)程完成快照備份即可, 父進(jìn)程不執(zhí)行由備份引起的磁盤I/O
• 與AOF模式相比, RDB在大數(shù)據(jù)集的情況下, 數(shù)據(jù)恢復(fù)時(shí), 服務(wù)重啟速度更快.

RDB缺點(diǎn)

• 如果你想要在Redis意外停止工作時(shí)(比如斷電), 最小可能的丟失數(shù)據(jù), RDB不是一個(gè)好的方案. 你可以在RDB生成的地方, 配置不同的保存點(diǎn)(比如每5分鐘,對(duì)數(shù)據(jù)集產(chǎn)生至少100次寫操作時(shí),創(chuàng)建一個(gè)保存點(diǎn), 你也可以配置多個(gè)保存點(diǎn)策略). 然而, 這樣你通常會(huì)在每5分鐘甚至更長(zhǎng)時(shí)間間隔才創(chuàng)建RDB快照, 所以當(dāng)Redis異常停止工作時(shí), 你會(huì)丟失最后產(chǎn)生快照時(shí)間點(diǎn)到現(xiàn)在的數(shù)據(jù).
• RDB會(huì)調(diào)用系統(tǒng)fork()方法派生一個(gè)子進(jìn)程來(lái)完成數(shù)據(jù)持久化到硬盤. 如果數(shù)據(jù)集比較大, Fork()方法會(huì)非常耗時(shí), 造成Redis停止為客戶端服務(wù), 停止時(shí)間可能是上微秒, 如果數(shù)據(jù)集非常大并且CPU性能不是很好, 停止時(shí)間可以達(dá)到1秒鐘或更多. 在持久化時(shí), AOF也會(huì)調(diào)用fork()方法, 但是你可以不帶任何協(xié)商(trade-off), 調(diào)整重寫日志的頻率.

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

使用AOF持久化程度更高: 你可以配置不同的fsync策略:

• 不帶fsync
• 每秒鐘一次fsync
• 每次查詢的時(shí)候fsync

注: fsync(https://man7.org/linux/man-pages/man2/fsync.2.html)是系統(tǒng)方法, 用于將內(nèi)核態(tài)的緩存數(shù)據(jù)持久化到存儲(chǔ)設(shè)備, 比如將內(nèi)存數(shù)據(jù)寫入硬盤

默認(rèn)使用每秒執(zhí)行一次fsync的策略, 這種場(chǎng)景下, Redis的寫性能也能非常好, 因?yàn)閒sync運(yùn)行在一個(gè)后臺(tái)線程, 而主線程會(huì)盡力完成寫操作. 所以你最多丟失1秒鐘的數(shù)據(jù).

• AOF日志是一個(gè)只能追加的文件, 所以在斷電后, 該文件不會(huì)出現(xiàn)查找(seek)或損壞的問(wèn)題. 即使由于磁盤滿或其他原因?qū)е氯罩局写嬖谥粚懥艘话氲拿? 也可以使用redis-check-aof工具輕松修復(fù).
• Redis會(huì)在AOF文件太大的時(shí)候, 自動(dòng)在后臺(tái)重寫日志. 重寫十分安全, 重寫時(shí), Redis派生一個(gè)子進(jìn)程將大的AOF文件重寫為最小可用的數(shù)據(jù)集日志文件, 此時(shí)有寫操作時(shí), Redis繼續(xù)追加到舊的AOF文件的同時(shí)也追加到AOF重寫緩沖區(qū)aof_rewrite_buf, 重寫完成時(shí), 新的小AOF文件將合并緩沖區(qū)中的新數(shù)據(jù), 最后將新的AOF文件重命名為老的AOF文件完成替換操作, 以后的數(shù)據(jù)將寫入新的AOF文件.
• AOF日志文件以一種容易理解和解析的格式依次記錄了所有的操作. 導(dǎo)出一個(gè)AOF文件非常容易. 甚至在失誤執(zhí)行了清除命令FLUSHALL(https://redis.io/commands/flushall) , 如果這時(shí)候重寫操作沒(méi)有被執(zhí)行, 你仍然可以通過(guò)關(guān)閉服務(wù), 刪除文件最后的錯(cuò)誤命令, 重啟Redis完成數(shù)據(jù)恢復(fù).

AOF缺點(diǎn)

• 對(duì)于相同的數(shù)據(jù)集, AOF文件一般比RDB文件大.
• 根據(jù)具體的fsync策略, AOF可能比RDB速度慢. 通常默認(rèn)的每秒fsync策略下, Reids性能也非常高, 如果禁用fsync, 即使在高負(fù)載的情況下, AOF的速度應(yīng)該和RDB一樣快. 盡管如此, 在巨大寫負(fù)載的情況下, RDB提供了更多最大延遲的保證.
• 在過(guò)去, 當(dāng)執(zhí)行一些特殊的命令時(shí)(比如這里有一個(gè)涉及到阻塞的命令BRPOPLPUSH:https://redis.io/commands/brpoplpush), Redis遇到了一些罕見的BUG, 它會(huì)導(dǎo)致AOF重建數(shù)據(jù)時(shí), 數(shù)據(jù)出現(xiàn)不一致.這些問(wèn)題非常罕見, 我們進(jìn)行了單元測(cè)試, 自動(dòng)創(chuàng)建隨機(jī)復(fù)雜的數(shù)據(jù)集來(lái)執(zhí)行重建測(cè)試, 沒(méi)有出現(xiàn)這些問(wèn)題. 但是如果使用RDB持久化, 幾乎不可能出現(xiàn)這類問(wèn)題. 為了清楚的說(shuō)明這一點(diǎn): AOF類似MySQL或者M(jìn)ongoDB, 采用增量更新現(xiàn)有狀態(tài)的工作機(jī)制, 但是RDB快照是每次從頭開始創(chuàng)建, 從概念上來(lái)說(shuō), RDB更具有魯棒性(健壯). 但是有以下兩點(diǎn)值得注意:

1. 每次AOF被Redis重寫的時(shí)候，它會(huì)從包含在數(shù)據(jù)集中的實(shí)際數(shù)據(jù)中從頭開始重新創(chuàng)建，使新AOF文件對(duì)bug的抵抗力比不重寫的, , 一直追加的AOF文件更強(qiáng).
2. 在實(shí)際使用中, 我們重來(lái)沒(méi)有收到過(guò)一個(gè)關(guān)于AOF文件出錯(cuò)的用戶報(bào)告.

那我該使用哪個(gè)?

通常, 如果你想獲得像PostgreSQL那樣的數(shù)據(jù)安全性, 你應(yīng)該結(jié)合RDB和AOF.

如果你非常關(guān)心你的數(shù)據(jù), 但是允許丟失幾分鐘的數(shù)據(jù), 你可以只使用RDB持久化.

有很多用戶只使用AOF, 但是我們不建議那樣做, 因?yàn)镽DB的基于時(shí)間點(diǎn)的快照在做數(shù)據(jù)庫(kù)備份, 快速重啟, 或AOF引擎出現(xiàn)問(wèn)題時(shí), 非常有用.

注意: 基于這些原因, 在將來(lái)(長(zhǎng)期計(jì)劃), 我們最終會(huì)統(tǒng)一AOF和RDB為一個(gè)持久化模型方案.

下面幾節(jié), 我們來(lái)舉例說(shuō)明更多, 關(guān)于RDB和AOF的細(xì)節(jié).

快照

Redis默認(rèn)保存快照到硬盤上的dump.rdb文件. 你可以配置, 每N分鐘, 至少出現(xiàn)了M次數(shù)據(jù)集改變執(zhí)行一次快照, 或者手動(dòng)執(zhí)行保存 SAVE 或后臺(tái)保存BGSAVE 命令.

save 60 1000 

它是如何工作的?

每當(dāng)Redis需要保存數(shù)據(jù)集到磁盤, 會(huì)執(zhí)行下面的任務(wù):

• Redis forks 派生子進(jìn)程, 這時(shí)候會(huì)存在一個(gè)父進(jìn)程和一個(gè)子進(jìn)程.
• 子進(jìn)程開始將數(shù)據(jù)集寫到RDB臨時(shí)文件.
• 當(dāng)子進(jìn)程完成新RDB文件寫入后, 會(huì)將原來(lái)的舊RDB文件替換.

這種方法就是Redis的寫即拷語(yǔ)義(copy-on-write)

AOF僅追加文件

快照不是很持久, 如果Redis服務(wù)異常停止, 掉電停止, 或者意外執(zhí)行了kill -9殺掉Redis服務(wù)進(jìn)程, 最后的數(shù)據(jù)寫入將會(huì)丟失. 雖然對(duì)于有些應(yīng)用來(lái)說(shuō)這是個(gè)小問(wèn)題, 但對(duì)于要求完全持久化的場(chǎng)景, RDB不是一個(gè)很好的選擇.

appendonly yes 

從現(xiàn)在開始, 每當(dāng)Redis收到一個(gè)改變數(shù)據(jù)集的命令(比如SET), 該操作將追加到AOF文件, 當(dāng)你重啟Redis時(shí), 會(huì)基于AOF文件重建數(shù)據(jù)集.

日志重寫

AOF文件大小隨著操作的增加而增加. 舉個(gè)例子, 如果你想遞增計(jì)數(shù)100次, 最終數(shù)據(jù)集中只包含一個(gè)鍵值就是最終的結(jié)果, 但是在AOF文件中有100條記錄, 實(shí)際上在重建數(shù)據(jù)集時(shí), 不需要剩余的99次記錄.

所以Redis支持這個(gè)有趣的功能: 在不中斷Redis服務(wù)的情況下, 后臺(tái)進(jìn)行AOF文件重寫. 當(dāng)執(zhí)行后臺(tái)重寫命令 BGREWRITEAOF 時(shí), Reids會(huì)將當(dāng)前內(nèi)存中的數(shù)據(jù)集以最短的有序命令集寫下來(lái). 如果你使用Redis2.2, 你需要定時(shí)執(zhí)行 BGREWRITEAOF(https://redis.io/commands/bgrewriteaof) , 從Redis2.4開始, 它可以自動(dòng)觸發(fā)日志重寫(更多信息可以查看2.4的配置示例, 不同版本的配置(https://redis.io/topics/config)).

AOF怎么持久化?

你可以配置時(shí)間間隔, Redis來(lái)執(zhí)行fsync到磁盤. 這里有三個(gè)策略:

• appendfsync always: 每個(gè)新的命令追加到AOF文件時(shí)執(zhí)行fsync. 非常慢, 但是非常安全. 注意, 如果追加的命令來(lái)自多個(gè)客戶端或管道的批量命令, 在發(fā)送響應(yīng)之前, 這會(huì)被當(dāng)做一次寫操作, 只會(huì)執(zhí)行一次fsync.
• appendfsync everysec: 每秒執(zhí)行一次fsync. 速度足夠快(在Redis2.4版本中, 與RDB快照的速度一樣快), 如果出現(xiàn)意外, 你最多丟失1秒的數(shù)據(jù).
• appendfsync no: 從不執(zhí)行 fsync, 只把數(shù)據(jù)交給操作系統(tǒng). 這雖然更快, 但是更不安全. 這種配置, 通常Linux會(huì)每30秒刷新一次數(shù)據(jù)到硬盤, 但實(shí)際時(shí)間可以通過(guò)內(nèi)核配置調(diào)優(yōu).

每秒執(zhí)行一次fsync是建議并且是默認(rèn)的方式. 它既快又安全. appendfsync always策略在實(shí)踐中非常慢, 但是支持組提交, 所以可以將多個(gè)并行寫操作合并, 執(zhí)行一次fsync即可.

如果AOF文件被截?cái)嗔藨?yīng)該怎么做?

在寫AOF文件時(shí), 服務(wù)器出現(xiàn)crash或磁盤空間滿了, 這時(shí)候AOF依然包含一致的數(shù)據(jù), 代表了給定時(shí)間點(diǎn)版本的數(shù)據(jù)集(默認(rèn)fsync策略可能會(huì)丟失1秒的數(shù)據(jù)), 但是最后的命令在AOF記錄中會(huì)被截?cái)? 最新的Redis主干版本依然會(huì)導(dǎo)入所有的AOF文件內(nèi)容, 但是會(huì)忽略最后的不完整的命令, 這時(shí)候, 服務(wù)器會(huì)發(fā)出警告日志:

* Reading RDB preamble from AOF file... 
* Reading the remaining AOF tail... 
# !!! Warning: short read while loading the AOF file !!! 
# !!! Truncating the AOF at offset 439 !!! 
# AOF loaded anyway because aof-load-truncated is enabled 

你可以改變默認(rèn)配置來(lái)強(qiáng)制停止這種事情發(fā)生, 但是默認(rèn)配置會(huì)忽略最后這個(gè)不完整的命令, 為了保證服務(wù)重啟后可用.

老版本的Redis不會(huì)自動(dòng)恢復(fù), 需要做以下步驟來(lái)恢復(fù):

• 對(duì)AOF文件進(jìn)行備份.
• 使用Redis提供的工具redis-check-aof 修復(fù)該AOF文件:
• $ redis-check-aof --fix
• 可以執(zhí)行 diff -u 檢查兩個(gè)AOF文件的差異, 確認(rèn)錯(cuò)誤被修復(fù).
• 用修復(fù)后的AOF文件重啟Redis服務(wù), 重建數(shù)據(jù)集.

AOF文件被損壞了怎么辦?

如果AOF文件不僅被截?cái)嗔? 中間還被插入了無(wú)效的字節(jié), 事情將變得更加復(fù)雜, Redis在啟動(dòng)的時(shí)候會(huì)中斷并提示:

* Reading the remaining AOF tail... 
# Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename> 

最好是用 redis-check-aof 工具修復(fù), 首先不適用 --fix 選項(xiàng), 找到問(wèn)題, 跳過(guò)該文件的錯(cuò)誤位置, 查看是否可以手動(dòng)修復(fù)該文件, AOF使用與Reids一致的協(xié)議格式,所以非常便于手動(dòng)修復(fù), 否則就使用工具修復(fù)該文件, 這種情況, 從無(wú)效的位置到文件結(jié)束的數(shù)據(jù)都可能被丟失, 如果損壞位置發(fā)生在開頭的位置, 則相當(dāng)于丟失整個(gè)數(shù)據(jù)集.

它是怎樣工作的?

日志重寫使用了與快照一致的拷貝即寫(copy-on-write)的方式, 步驟如下:

• Redis執(zhí)行 forks派生, 這樣就有一個(gè)主進(jìn)程和一個(gè)子進(jìn)程.
• 子進(jìn)程開始寫入一個(gè)新的AOF到零時(shí)文件中.
• Redis繼續(xù)追加到舊的AOF文件的同時(shí)也追加到AOF重寫緩沖區(qū)aof_rewrite_buf, 所以即使重新失敗, 也是數(shù)據(jù)安全的.
• 當(dāng)子進(jìn)程完成了AOF文件重寫, 父進(jìn)程收到一個(gè)完成信號(hào), 將緩存中的數(shù)據(jù)追加到新的AOF文件.
• 最后將新的AOF文件重命名為老的AOF文件完成替換操作, 以后的數(shù)據(jù)將寫入新的AOF文件.

怎樣從dump.rdb快照切換到AOF

在Redis2.0和Redis2.2用不同的步驟來(lái)切換到AOF, 而且Redis2.2切換到AOF更簡(jiǎn)單, 不需要重啟.

Redis >= 2.2

• 將最近的dump.rdb文件備份.
• 將備份文件傳輸?shù)桨踩牡胤?
• 執(zhí)行以下兩個(gè)命令:

1. redis-cli config set save "" #取消RDB
2. redis-cli config set appendonly yes #開啟AOF

• 檢查確認(rèn)數(shù)據(jù)庫(kù)中的鍵個(gè)數(shù)沒(méi)有丟失.
• 檢查寫操作都正確的追加進(jìn)了AOF文件.

第一個(gè)配置命令表示啟用AOF功能. 這樣Redis會(huì)阻塞來(lái)生成初始的備份, 然后打開新文件來(lái)寫入操作記錄, 后面的寫操作將會(huì)持續(xù)追加到該AOF文件中.

第二個(gè)配置命令用來(lái)關(guān)閉RDB快照持久化. 這是可選的, 如果保留save表示同時(shí)使用RDB和AOF持久化.

重要: 記住同時(shí)修改redis.conf配置文件來(lái)打開AOF, 否則服務(wù)重啟時(shí)將使用原來(lái)的配置.

Redis 2.0

• 將最近的dump.rdb文件備份.
• 將備份文件傳輸?shù)桨踩牡胤?
• 停止所有寫操作.
• 執(zhí)行后臺(tái)重寫AOF命令redis-cli BGREWRITEAOF. 該操作會(huì)創(chuàng)建AOF文件.
• 當(dāng)AOF備份完成后, 停止Redis服務(wù).
• 編輯redis.conf, 啟用AOF功能.
• 重啟服務(wù)
• 檢查確認(rèn)數(shù)據(jù)庫(kù)中的鍵個(gè)數(shù)沒(méi)有丟失.
• 檢查寫操作都正確的追加進(jìn)了AOF文件.

在AOF和RDB之間交互

Redis >= 2.4會(huì)保證當(dāng)RDB快照在運(yùn)行時(shí), 避免觸發(fā)一個(gè)AOF重寫進(jìn)程, 或者當(dāng)AOF重寫已經(jīng)運(yùn)行時(shí), 不允許后臺(tái)保存快照BGSAVE. 這可以防止兩個(gè)后臺(tái)進(jìn)程同時(shí)產(chǎn)生高負(fù)載的磁盤I/O.

備份Redis數(shù)據(jù)

開始本節(jié)內(nèi)容前, 請(qǐng)確認(rèn)已經(jīng)對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份, 如果磁盤損壞, 云實(shí)例消失等, 沒(méi)有備份意味著數(shù)據(jù)面臨著巨大風(fēng)險(xiǎn), 會(huì)消失在"黑洞" /dev/null中.

Redis對(duì)于數(shù)據(jù)備份非常友好, 即使數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)運(yùn)行中也允許你對(duì)數(shù)據(jù)進(jìn)行拷貝備份: RDB文件產(chǎn)生時(shí)就不會(huì)被修改, 快照備份期間, 它會(huì)生成零時(shí)的文件, 當(dāng)快照最終備份完成后采用重命名替換原來(lái)的RDB文件.

這意味著服務(wù)在運(yùn)行時(shí), 拷貝RDB文件是非常安全的, 下面是我們的建議:

• 在服務(wù)器上, 創(chuàng)建定時(shí)任務(wù)CronJob, 每小時(shí)執(zhí)行一次RDB快照, 保存到一個(gè)目錄, 并且在另外一個(gè)目錄下保存每日快照.
• 每次定時(shí)任務(wù)執(zhí)行時(shí), 確認(rèn)使用find命令查找最舊的快照, 將它們刪除, 對(duì)于每小時(shí)快照, 你可以保留最近48小時(shí), 對(duì)于每天快照, 你可以保留1~2個(gè)月. 并確包快照名包含時(shí)間信息.
• 每天至少做一次數(shù)據(jù)轉(zhuǎn)存, 比如將RDB快照轉(zhuǎn)存到其他數(shù)據(jù)中心, 或者至少?gòu)漠?dāng)前Redis服務(wù)物理機(jī)轉(zhuǎn)存到其他地方.

如果你使用ROF持久化方式, 仍然可以拷貝AOF文件來(lái)做備份. 這個(gè)AOF文件即使丟失最后一小段數(shù)據(jù), Redis也可以重建它們(請(qǐng)參考上面的截?cái)郃OF文件處理方式)

災(zāi)難恢復(fù)

災(zāi)難恢復(fù)和備份基本是一致的, 加上可以在許多不同的數(shù)據(jù)中心間轉(zhuǎn)存這些備份數(shù)據(jù). 這種情況下, 即使影響到最主要的數(shù)據(jù)中心, 其他地方的備份也是安全并且可以恢復(fù)的.

針對(duì)剛起步, 沒(méi)有太多的資金來(lái)做大型備份, 這里也提供了一些不需要太大開銷的災(zāi)備恢復(fù)技術(shù):

• AmazonS3對(duì)象存儲(chǔ)或其他類似服務(wù)是一個(gè)實(shí)現(xiàn)災(zāi)備恢復(fù)系統(tǒng)的好方法. 只需將每小時(shí)或每日的RDB快照加密后傳輸?shù)絊3即可, 你可以使用gpg -c(使用對(duì)稱加密模式)對(duì)數(shù)據(jù)加密. 請(qǐng)確認(rèn)將密碼保存到不同的安全的地方(比如拷貝一份交給最重要的人來(lái)管理). 建議使用多種存儲(chǔ)服務(wù)來(lái)提高數(shù)據(jù)安全性.
• 使用SCP(SSH的一部分)命令來(lái)將數(shù)據(jù)轉(zhuǎn)存到其他服務(wù)器. 這是一個(gè)簡(jiǎn)單而且安全的方法: 在云端, 獲取遠(yuǎn)離當(dāng)前Redis服務(wù)的一個(gè)小型虛擬專用服務(wù)器VPS, 在數(shù)據(jù)端, 安裝ssh, 生成不帶密碼的ssh客戶端密鑰, 將它添加到VPS的authorized_keys文件, 這樣就可以繼續(xù)實(shí)現(xiàn)自動(dòng)免密轉(zhuǎn)存?zhèn)浞輸?shù)據(jù)到VPS, 為了提高數(shù)據(jù)安全, 可以使用不同運(yùn)營(yíng)商, 不同網(wǎng)絡(luò)區(qū)域的VPS.

這種方式可能會(huì)導(dǎo)致文件傳輸失敗, 所以在傳輸完成后, 至少要增加文件完整性校驗(yàn), 比如校驗(yàn)文件大小, 如果使用VPS, 甚至可以使用SHA1校驗(yàn).

你也需要部署獨(dú)立的監(jiān)控報(bào)警系統(tǒng), 對(duì)備份過(guò)程進(jìn)行監(jiān)控, 在備份失敗時(shí)能及時(shí)發(fā)現(xiàn)并修復(fù).

參考文檔

Redis官方文檔: https://redis.io/topics/persistence