10.redis的RDB和AOF兩種持久化機制的優(yōu)劣勢對比

課程大綱

1戏售、RDB和AOF兩種持久化機制的介紹
2霸旗、RDB持久化機制的優(yōu)點
3签舞、RDB持久化機制的缺點
4榔昔、AOF持久化機制的優(yōu)點
5、AOF持久化機制的缺點
6瘪菌、RDB和AOF到底該如何選擇

我們已經知道對于一個企業(yè)級的redis架構來說撒会,持久化是不可減少的

企業(yè)級redis集群架構:海量數(shù)據(jù)、高并發(fā)师妙、高可用

持久化主要是做災難恢復诵肛,數(shù)據(jù)恢復,也可以歸類到高可用的一個環(huán)節(jié)里面去

比如你redis整個掛了,然后redis就不可用了怔檩,你要做的事情是讓redis變得可用褪秀,盡快變得可用

重啟redis,盡快讓它對外提供服務薛训,但是就像上一講說媒吗,如果你沒做數(shù)據(jù)備份,這個時候redis啟動了乙埃,也不可用啊闸英,數(shù)據(jù)都沒了

很可能說,大量的請求過來介袜,緩存全部無法命中甫何,在redis里根本找不到數(shù)據(jù),這個時候就死定了遇伞,緩存雪崩問題辙喂,所有請求,沒有在redis命中鸠珠,就會去mysql數(shù)據(jù)庫這種數(shù)據(jù)源頭中去找巍耗,一下子mysql承接高并發(fā),然后就掛了

mysql掛掉渐排,你都沒法去找數(shù)據(jù)恢復到redis里面去芍锦,redis的數(shù)據(jù)從哪兒來?從mysql來飞盆。娄琉。。

具體的完整的緩存雪崩的場景吓歇,還有企業(yè)級的解決方案孽水,到后面講

如果你把redis的持久化做好,備份和恢復方案做到企業(yè)級的程度城看,那么即使你的redis故障了女气,也可以通過備份數(shù)據(jù),快速恢復测柠,一旦恢復立即對外提供服務

redis的持久化炼鞠,跟高可用,是有關系的轰胁,企業(yè)級redis架構中去講解

redis持久化:RDB谒主,AOF


1、RDB和AOF兩種持久化機制的介紹

RDB持久化機制赃阀,對redis中的數(shù)據(jù)執(zhí)行周期性的持久化

AOF機制對每條寫入命令作為日志霎肯,以append-only的模式寫入一個日志文件中,在redis重啟的時候,可以通過回放AOF日志中的寫入指令來重新構建整個數(shù)據(jù)集

如果我們想要redis僅僅作為純內存的緩存來用观游,那么可以禁止RDB和AOF所有的持久化機制

通過RDB或AOF搂捧,都可以將redis內存中的數(shù)據(jù)給持久化到磁盤上面來,然后可以將這些數(shù)據(jù)備份到別的地方去懂缕,比如說阿里云允跑,云服務

如果redis掛了,服務器上的內存和磁盤上的數(shù)據(jù)都丟了搪柑,可以從云服務上拷貝回來之前的數(shù)據(jù)聋丝,放到指定的目錄中,然后重新啟動redis拌屏,redis就會自動根據(jù)持久化數(shù)據(jù)文件中的數(shù)據(jù),去恢復內存中的數(shù)據(jù)术荤,繼續(xù)對外提供服務

如果同時使用RDB和AOF兩種持久化機制倚喂,那么在redis重啟的時候,會使用AOF來重新構建數(shù)據(jù)瓣戚,因為AOF中的數(shù)據(jù)更加完整


2端圈、RDB持久化機制的優(yōu)點

(1)RDB會生成多個數(shù)據(jù)文件,每個數(shù)據(jù)文件都代表了某一個時刻中redis的數(shù)據(jù)子库,這種多個數(shù)據(jù)文件的方式舱权,非常適合做冷備,可以將這種完整的數(shù)據(jù)文件發(fā)送到一些遠程的安全存儲上去仑嗅,比如說Amazon的S3云服務上去宴倍,在國內可以是阿里云的ODPS分布式存儲上,以預定好的備份策略來定期備份redis中的數(shù)據(jù)

RDB也可以做冷備仓技,生成多個文件鸵贬,每個文件都代表了某一個時刻的完整的數(shù)據(jù)快照
AOF也可以做冷備,只有一個文件脖捻,但是你可以阔逼,每隔一定時間,去copy一份這個文件出來

RDB做冷備地沮,優(yōu)勢在哪兒呢嗜浮?由redis去控制固定時長生成快照文件的事情,比較方便; AOF摩疑,還需要自己寫一些腳本去做這個事情危融,各種定時
RDB數(shù)據(jù)做冷備,在最壞的情況下雷袋,提供數(shù)據(jù)恢復的時候专挪,速度比AOF快

(2)RDB對redis對外提供的讀寫服務,影響非常小,可以讓redis保持高性能寨腔,因為redis主進程只需要fork一個子進程速侈,讓子進程執(zhí)行磁盤IO操作來進行RDB持久化即可

RDB,每次寫迫卢,都是直接寫redis內存倚搬,只是在一定的時候,才會將數(shù)據(jù)寫入磁盤中
AOF乾蛤,每次都是要寫文件的每界,雖然可以快速寫入os cache中,但是還是有一定的時間開銷的,速度肯定比RDB略慢一些

(3)相對于AOF持久化機制來說家卖,直接基于RDB數(shù)據(jù)文件來重啟和恢復redis進程眨层,更加快速

AOF,存放的指令日志上荡,做數(shù)據(jù)恢復的時候趴樱,其實是要回放和執(zhí)行所有的指令日志,來恢復出來內存中的所有數(shù)據(jù)的
RDB酪捡,就是一份數(shù)據(jù)文件叁征,恢復的時候,直接加載到內存中即可

結合上述優(yōu)點逛薇,RDB特別適合做冷備份捺疼,冷備


3、RDB持久化機制的缺點

(1)如果想要在redis故障時永罚,盡可能少的丟失數(shù)據(jù)啤呼,那么RDB沒有AOF好。一般來說呢袱,RDB數(shù)據(jù)快照文件媳友,都是每隔5分鐘,或者更長時間生成一次产捞,這個時候就得接受一旦redis進程宕機醇锚,那么會丟失最近5分鐘的數(shù)據(jù)

這個問題,也是rdb最大的缺點坯临,就是不適合做第一優(yōu)先的恢復方案焊唬,如果你依賴RDB做第一優(yōu)先恢復方案,會導致數(shù)據(jù)丟失的比較多

(2)RDB每次在fork子進程來執(zhí)行RDB快照數(shù)據(jù)文件生成的時候看靠,如果數(shù)據(jù)文件特別大赶促,可能會導致對客戶端提供的服務暫停數(shù)毫秒,或者甚至數(shù)秒

一般不要讓RDB的間隔太長挟炬,否則每次生成的RDB文件太大了鸥滨,對redis本身的性能可能會有影響的


4嗦哆、AOF持久化機制的優(yōu)點

(1)AOF可以更好的保護數(shù)據(jù)不丟失,一般AOF會每隔1秒婿滓,通過一個后臺線程執(zhí)行一次fsync操作老速,最多丟失1秒鐘的數(shù)據(jù)

每隔1秒,就執(zhí)行一次fsync操作凸主,保證os cache中的數(shù)據(jù)寫入磁盤中

redis進程掛了橘券,最多丟掉1秒鐘的數(shù)據(jù)

(2)AOF日志文件以append-only模式寫入,所以沒有任何磁盤尋址的開銷卿吐,寫入性能非常高旁舰,而且文件不容易破損,即使文件尾部破損嗡官,也很容易修復

(3)AOF日志文件即使過大的時候箭窜,出現(xiàn)后臺重寫操作,也不會影響客戶端的讀寫。因為在rewrite log的時候,會對其中的指導進行壓縮形病,創(chuàng)建出一份需要恢復數(shù)據(jù)的最小日志出來。再創(chuàng)建新日志文件的時候坊罢,老的日志文件還是照常寫入续担。當新的merge后的日志文件ready的時候擅耽,再交換新老日志文件即可。

(4)AOF日志文件的命令通過非澄镉觯可讀的方式進行記錄乖仇,這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有數(shù)據(jù)询兴,只要這個時候后臺rewrite還沒有發(fā)生乃沙,那么就可以立即拷貝AOF文件,將最后一條flushall命令給刪了诗舰,然后再將該AOF文件放回去警儒,就可以通過恢復機制,自動恢復所有數(shù)據(jù)


5眶根、AOF持久化機制的缺點

(1)對于同一份數(shù)據(jù)來說蜀铲,AOF日志文件通常比RDB數(shù)據(jù)快照文件更大

(2)AOF開啟后,支持的寫QPS會比RDB支持的寫QPS低属百,因為AOF一般會配置成每秒fsync一次日志文件记劝,當然,每秒一次fsync族扰,性能也還是很高的

如果你要保證一條數(shù)據(jù)都不丟厌丑,也是可以的定欧,AOF的fsync設置成沒寫入一條數(shù)據(jù),fsync一次怒竿,那就完蛋了砍鸠,redis的QPS大降

(3)以前AOF發(fā)生過bug,就是通過AOF記錄的日志愧口,進行數(shù)據(jù)恢復的時候睦番,沒有恢復一模一樣的數(shù)據(jù)出來。所以說耍属,類似AOF這種較為復雜的基于命令日志/merge/回放的方式托嚣,比基于RDB每次持久化一份完整的數(shù)據(jù)快照文件的方式,更加脆弱一些厚骗,容易有bug示启。不過AOF就是為了避免rewrite過程導致的bug,因此每次rewrite并不是基于舊的指令日志進行merge的领舰,而是基于當時內存中的數(shù)據(jù)進行指令的重新構建夫嗓,這樣健壯性會好很多。

(4)唯一的比較大的缺點冲秽,其實就是做數(shù)據(jù)恢復的時候舍咖,會比較慢,還有做冷備锉桑,定期的備份排霉,不太方便,可能要自己手寫復雜的腳本去做民轴,做冷備不太合適


6攻柠、RDB和AOF到底該如何選擇

(1)不要僅僅使用RDB,因為那樣會導致你丟失很多數(shù)據(jù)

(2)也不要僅僅使用AOF后裸,因為那樣有兩個問題瑰钮,第一,你通過AOF做冷備微驶,沒有RDB做冷備浪谴,來的恢復速度更快; 第二,RDB每次簡單粗暴生成數(shù)據(jù)快照因苹,更加健壯苟耻,可以避免AOF這種復雜的備份和恢復機制的bug

(3)綜合使用AOF和RDB兩種持久化機制,用AOF來保證數(shù)據(jù)不丟失容燕,作為數(shù)據(jù)恢復的第一選擇; 用RDB來做不同程度的冷備梁呈,在AOF文件都丟失或損壞不可用的時候,還可以使用RDB來進行快速的數(shù)據(jù)恢復


RDB丟失數(shù)據(jù)的問題.png
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末蘸秘,一起剝皮案震驚了整個濱河市官卡,隨后出現(xiàn)的幾起案子蝗茁,更是在濱河造成了極大的恐慌,老刑警劉巖寻咒,帶你破解...
    沈念sama閱讀 211,194評論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件哮翘,死亡現(xiàn)場離奇詭異,居然都是意外死亡毛秘,警方通過查閱死者的電腦和手機饭寺,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,058評論 2 385
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來叫挟,“玉大人艰匙,你說我怎么就攤上這事∧遥” “怎么了员凝?”我有些...
    開封第一講書人閱讀 156,780評論 0 346
  • 文/不壞的土叔 我叫張陵,是天一觀的道長奋献。 經常有香客問我健霹,道長,這世上最難降的妖魔是什么瓶蚂? 我笑而不...
    開封第一講書人閱讀 56,388評論 1 283
  • 正文 為了忘掉前任糖埋,我火速辦了婚禮,結果婚禮上窃这,老公的妹妹穿的比我還像新娘瞳别。我一直安慰自己,他們只是感情好钦听,可當我...
    茶點故事閱讀 65,430評論 5 384
  • 文/花漫 我一把揭開白布洒试。 她就那樣靜靜地躺著倍奢,像睡著了一般朴上。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上卒煞,一...
    開封第一講書人閱讀 49,764評論 1 290
  • 那天痪宰,我揣著相機與錄音,去河邊找鬼畔裕。 笑死衣撬,一個胖子當著我的面吹牛,可吹牛的內容都是我干的扮饶。 我是一名探鬼主播具练,決...
    沈念sama閱讀 38,907評論 3 406
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼甜无!你這毒婦竟也來了扛点?” 一聲冷哼從身側響起哥遮,我...
    開封第一講書人閱讀 37,679評論 0 266
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎陵究,沒想到半個月后眠饮,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經...
    沈念sama閱讀 44,122評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡铜邮,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,459評論 2 325
  • 正文 我和宋清朗相戀三年仪召,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片松蒜。...
    茶點故事閱讀 38,605評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡扔茅,死狀恐怖,靈堂內的尸體忽然破棺而出秸苗,到底是詐尸還是另有隱情咖摹,我是刑警寧澤,帶...
    沈念sama閱讀 34,270評論 4 329
  • 正文 年R本政府宣布难述,位于F島的核電站萤晴,受9級特大地震影響,放射性物質發(fā)生泄漏胁后。R本人自食惡果不足惜店读,卻給世界環(huán)境...
    茶點故事閱讀 39,867評論 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望攀芯。 院中可真熱鬧屯断,春花似錦、人聲如沸侣诺。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,734評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽年鸳。三九已至趴久,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間搔确,已是汗流浹背彼棍。 一陣腳步聲響...
    開封第一講書人閱讀 31,961評論 1 265
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留膳算,地道東北人座硕。 一個月前我還...
    沈念sama閱讀 46,297評論 2 360
  • 正文 我出身青樓,卻偏偏與公主長得像涕蜂,于是被迫代替她去往敵國和親华匾。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 43,472評論 2 348

推薦閱讀更多精彩內容

  • 前言 在上一篇文章中机隙,介紹了Redis內存模型蜘拉,從這篇文章開始刊头,將依次介紹Redis高可用相關的知識——持久化、復...
    Java架構閱讀 2,304評論 3 21
  • 一诸尽、Redis高可用概述 在介紹Redis高可用之前原杂,先說明一下在Redis的語境中高可用的含義。 我們知道您机,在w...
    空語閱讀 1,593評論 0 2
  • 從這篇文章開始穿肄,將依次介紹Redis高可用相關的知識——持久化、復制(及讀寫分離)际看、哨兵咸产、以及集群。 本文將先說明...
    不變甄心閱讀 692評論 0 4
  • 笛卡爾的這句話大家都耳熟能詳仲闽。他憑借著這種思想而贏得了“現(xiàn)代哲學之父”的美譽脑溢。跟泰勒斯的“哲學之父”相比,多了一個...
    如一書閱讀 298評論 2 3
  • 今天出差了赖欣,嬌丫頭和超哥跟著姥姥姥爺屑彻,上午打了幾個電話詢問了一下作業(yè)完成情況,我現(xiàn)在還在高速上……想孩...
    鑫姐和嬌丫頭閱讀 180評論 0 1