在生產(chǎn)環(huán)境中我們需要保證 Redis 實(shí)例中數(shù)據(jù)的可靠性坪郭,防止數(shù)據(jù)丟失。為此需要了解Redis的持久化方式。本文主要介紹Redis提供的持久化方式。
- RDB 在指定時(shí)間間隔內(nèi)生成時(shí)間點(diǎn)的數(shù)據(jù)快照(point-in-time snapshot)等浊。
- AOF(append-only file)記錄服務(wù)器執(zhí)行的所有寫操作命令,并在服務(wù)器啟動(dòng)時(shí)摹蘑,通過重新執(zhí)行這些命令來還原數(shù)據(jù)集筹燕。 AOF 文件中的命令全部以 Redis 協(xié)議的格式來保存,新命令會(huì)被追加到文件的末尾衅鹿。 Redis 還可以在后臺(tái)對(duì) AOF 文件進(jìn)行重寫(rewrite)撒踪,使得 AOF 文件的體積不會(huì)超出保存數(shù)據(jù)集狀態(tài)所需的實(shí)際大小。
- 同時(shí)使用RDB大渤、AOF 兩種方式制妄。 在這種情況下, 當(dāng) Redis 重啟時(shí)泵三, 它會(huì)優(yōu)先使用 AOF 文件來還原數(shù)據(jù)集耕捞, 因?yàn)?AOF 文件保存的數(shù)據(jù)集通常比 RDB 文件所保存的數(shù)據(jù)集更完整。
Redis 官方推薦同時(shí)使用 RDB 和 AOF 兩種持久化方式切黔。官方在未來可能會(huì)將兩種持久化方式整合成單個(gè)持久化模型砸脊。
RDB 的優(yōu)點(diǎn)
最主要的有點(diǎn)就是數(shù)據(jù)文件小恢復(fù)速度快具篇。
- RDB 是一個(gè)非常緊湊(compact)的文件纬霞,它保存了 Redis 在某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)集。 這種文件非常適合用于進(jìn)行備份: 比如說驱显,你可以在最近的 24 小時(shí)內(nèi)诗芜,每小時(shí)備份一次 RDB 文件瞳抓,并且在每個(gè)月的每一天,也備份一個(gè) RDB 文件伏恐。 這樣的話孩哑,即使遇上問題,也可以隨時(shí)將數(shù)據(jù)集還原到不同的版本翠桦。
- RDB 非常適用于災(zāi)難恢復(fù)(disaster recovery):它只有一個(gè)文件横蜒,并且內(nèi)容都非常緊湊,可以(在加密后)將它傳送到別的數(shù)據(jù)中心销凑,或者亞馬遜 S3 中丛晌。
- RDB 可以最大化 Redis 的性能:父進(jìn)程在保存 RDB 文件時(shí)唯一要做的就是 fork
出一個(gè)子進(jìn)程,然后這個(gè)子進(jìn)程就會(huì)處理接下來的所有保存工作斗幼,父進(jìn)程無須執(zhí)行任何磁盤 I/O 操作澎蛛。 - RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比 AOF 的恢復(fù)速度要快。
RDB 的缺點(diǎn)
存在數(shù)據(jù)丟失風(fēng)險(xiǎn)蜕窿。數(shù)據(jù)集較大時(shí)保存操作非常耗時(shí)谋逻,會(huì)造成服務(wù)器在短暫的時(shí)間內(nèi)(毫秒級(jí))停止處理客戶端請(qǐng)求。
- 如果你需要盡量避免在服務(wù)器故障時(shí)丟失數(shù)據(jù)桐经,那么 RDB 不適合你毁兆。 雖然 Redis 允許你設(shè)置不同的保存點(diǎn)(save point)來控制保存 RDB 文件的頻率, 但是阴挣, 因?yàn)镽DB 文件需要保存整個(gè)數(shù)據(jù)集的狀態(tài)荧恍, 所以它并不是一個(gè)輕松的操作。 因此你可能會(huì)至少 5 分鐘才保存一次 RDB 文件屯吊。 在這種情況下送巡, 一旦發(fā)生故障停機(jī), 你就可能會(huì)丟失好幾分鐘的數(shù)據(jù)盒卸。
- 每次保存 RDB 的時(shí)候骗爆,Redis 都要 fork() 出一個(gè)子進(jìn)程,并由子進(jìn)程來進(jìn)行實(shí)際的持久化工作蔽介。 在數(shù)據(jù)集比較龐大時(shí)摘投, fork() 可能會(huì)非常耗時(shí),造成服務(wù)器在某某毫秒內(nèi)停止處理客戶端虹蓄; 如果數(shù)據(jù)集非常巨大犀呼,并且 CPU 時(shí)間非常緊張的話,那么這種停止時(shí)間甚至可能會(huì)長(zhǎng)達(dá)整整一秒薇组。 雖然 AOF 重寫也需要進(jìn)行 fork() 外臂,但無論 AOF 重寫的執(zhí)行間隔有多長(zhǎng),數(shù)據(jù)的耐久性都不會(huì)有任何損失律胀。
AOF 的優(yōu)點(diǎn)
可以指定不同的fsync策略宋光,不會(huì)發(fā)生數(shù)據(jù)丟失
- 使用 AOF 持久化會(huì)讓 Redis 變得非常耐久(much more durable):你可以設(shè)置不同的 fsync 策略貌矿,比如無 fsync ,每秒鐘一次 fsync 罪佳,或者每次執(zhí)行寫入命令時(shí) fsync 逛漫。 AOF 的默認(rèn)策略為每秒鐘 fsync 一次,在這種配置下赘艳,Redis 仍然可以保持良好的性能酌毡,并且就算發(fā)生故障停機(jī),也最多只會(huì)丟失一秒鐘的數(shù)據(jù)( fsync 會(huì)在后臺(tái)線程執(zhí)行蕾管,所以主線程可以繼續(xù)努力地處理命令請(qǐng)求)阔馋。
- AOF 文件是一個(gè)只進(jìn)行追加操作的日志文件(append only log), 因此對(duì) AOF 文件的寫入不需要進(jìn)行 seek 娇掏, 即使日志因?yàn)槟承┰蚨宋磳懭胪暾拿睿ū热鐚懭霑r(shí)磁盤已滿呕寝,寫入中途停機(jī),等等)婴梧, redis-check-aof 工具也可以輕易地修復(fù)這種問題下梢。
- Redis 可以在 AOF 文件體積變得過大時(shí),自動(dòng)地在后臺(tái)對(duì) AOF 進(jìn)行重寫: 重寫后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合塞蹭。 整個(gè)重寫操作是絕對(duì)安全的孽江,因?yàn)?Redis 在創(chuàng)建新 AOF 文件的過程中,會(huì)繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面番电,即使重寫過程中發(fā)生停機(jī)岗屏,現(xiàn)有的 AOF 文件也不會(huì)丟失。 而一旦新 AOF 文件創(chuàng)建完畢漱办,Redis 就會(huì)從舊 AOF 文件切換到新 AOF 文件这刷,并開始對(duì)新 AOF 文件進(jìn)行追加操作。
- AOF 文件有序地保存了對(duì)數(shù)據(jù)庫執(zhí)行的所有寫入操作娩井, 這些寫入操作以 Redis 協(xié)議的格式保存暇屋, 因此 AOF 文件的內(nèi)容非常容易被人讀懂, 對(duì)文件進(jìn)行分析(parse)也很輕松洞辣。 導(dǎo)出(export) AOF 文件也非常簡(jiǎn)單: 舉個(gè)例子咐刨, 如果你不小心執(zhí)行了 FLUSHALL 命令, 但只要 AOF 文件未被重寫扬霜, 那么只要停止服務(wù)器定鸟, 移除 AOF 文件末尾的 FLUSHALL 命令, 并重啟 Redis 著瓶, 就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)联予。
AOF 的缺點(diǎn)
備份速度慢于RDB,備份文件體積大于RDB。
- 對(duì)于相同的數(shù)據(jù)集來說躯泰,AOF 文件的體積通常要大于 RDB 文件的體積。
- 根據(jù)所使用的 fsync 策略华糖,AOF 的速度可能會(huì)慢于 RDB 麦向。 在一般情況下, 每秒 fsync 的性能依然非常高客叉, 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快诵竭, 即使在高負(fù)荷之下也是如此。 不過在處理巨大的寫入載入時(shí)兼搏,RDB 可以提供更有保證的最大延遲時(shí)間(latency)卵慰。
- AOF 在過去曾經(jīng)發(fā)生過這樣的 bug : 因?yàn)閭€(gè)別命令的原因,導(dǎo)致 AOF 文件在重新載入時(shí)佛呻,無法將數(shù)據(jù)集恢復(fù)成保存時(shí)的原樣裳朋。 (舉個(gè)例子,阻塞命令 BRPOPLPUSH 就曾經(jīng)引起過這樣的 bug 吓著。) 測(cè)試套件里為這種情況添加了測(cè)試: 它們會(huì)自動(dòng)生成隨機(jī)的鲤嫡、復(fù)雜的數(shù)據(jù)集, 并通過重新載入這些數(shù)據(jù)來確保一切正常绑莺。 雖然這種 bug 在 AOF 文件中并不常見暖眼, 但是對(duì)比來說, RDB 幾乎是不可能出現(xiàn)這種 bug 的纺裁。
本文內(nèi)容大部分來源于以下兩篇文章: