redis 持久化詳解

關(guān)于redis的安裝和基本使用熏矿,參考本人博客:

redis安裝和基礎(chǔ)入門

Redis數(shù)據(jù)庫的學(xué)習與實踐—Redis的常用命令及高級應(yīng)用

1 redis持久化(persistence)

1.1 Redis 提供了多種不同級別的持久化方式

  1. RDB 持久化可以在指定的時間間隔內(nèi)生成數(shù)據(jù)集的時間點快照(point-in-time snapshot)。
  2. AOF 持久化記錄服務(wù)器執(zhí)行的所有寫操作命令讲竿,并在服務(wù)器啟動時贴彼,通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。 AOF 文件中的命令全部以 Redis 協(xié)議的格式來保存,新命令會被追加到文件的末尾。 Redis 還可以在后臺對 AOF 文件進行重寫(rewrite)螺戳,使得 AOF 文件的體積不會超出保存數(shù)據(jù)集狀態(tài)所需的實際大小。

Redis 還可以同時使用 AOF 持久化和 RDB 持久化桥氏。 在這種情況下温峭, 當 Redis 重啟時猛铅, 它會優(yōu)先使用 AOF 文件來還原數(shù)據(jù)集字支, 因為 AOF 文件保存的數(shù)據(jù)集通常比 RDB 文件所保存的數(shù)據(jù)集更完整。

也可以關(guān)閉持久化功能奸忽,讓數(shù)據(jù)只在服務(wù)器運行時存在堕伪。

1.2 RDB 模式

1.2.1 配置方式

RDB 復(fù)制模式也稱作快照模式,在指定時間間隔中保存數(shù)據(jù)快照栗菜。

save <seconds> <changes>

在 seconds 時間間隔中發(fā)生changes次數(shù)的變化欠雌,就觸發(fā)一次快照保存「沓铮可以配置多條規(guī)則富俄。

除了在redis的配置文件中配置快照的規(guī)則外,還可以手動直接觸發(fā)一次快照而咆。直接調(diào)用SAVE 或者 BGSAVE命令霍比。

1.2.2 工作原理

當 Redis 需要保存 dump.rdb 文件時, 服務(wù)器執(zhí)行以下操作:

  1. Redis 調(diào)用 fork() 暴备,同時擁有父進程和子進程悠瞬。
  2. 子進程將數(shù)據(jù)集寫入到一個臨時 RDB 文件中。
  3. 當子進程完成對新 RDB 文件的寫入時,Redis 用新 RDB 文件替換原來的 RDB 文件浅妆,并刪除舊的 RDB 文件望迎。

這種工作方式使得 Redis 可以從寫時復(fù)制(copy-on-write)機制中獲益

1.2.3 優(yōu)缺點

優(yōu)點

  1. RDB 是一個非常緊湊(compact)的文件,它保存了 Redis 在某個時間點上的數(shù)據(jù)集凌外。 這種文件非常適合用于進行備份: 比如說辩尊,你可以在最近的 24 小時內(nèi),每小時備份一次 RDB 文件康辑,并且在每個月的每一天对省,也備份一個 RDB 文件。 這樣的話晾捏,即使遇上問題蒿涎,也可以隨時將數(shù)據(jù)集還原到不同的版本。
  2. RDB 非常適用于災(zāi)難恢復(fù)(disaster recovery):它只有一個文件惦辛,并且內(nèi)容都非常緊湊劳秋,可以(在加密后)將它傳送到別的數(shù)據(jù)中心。
  3. RDB 可以最大化 Redis 的性能:父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程胖齐,然后這個子進程就會處理接下來的所有保存工作玻淑,父進程無須執(zhí)行任何磁盤 I/O 操作。
  4. RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快呀伙。

缺點

  1. rdb模式按照指定時間發(fā)生幾次變化來持久化數(shù)據(jù)补履,這就有可能在數(shù)據(jù)沒有發(fā)生持久化的時候就宕機,導(dǎo)致當前時間段內(nèi)的數(shù)據(jù)丟失
  2. 每次rdb回fork子進程進行剿另,當數(shù)據(jù)量比較大的時候fork很耗時間箫锤,CPU緊張的時候更容易出現(xiàn)卡頓。

1.3 AOF(AppendOnly File) 模式

在服務(wù)器突然斷電雨女,死機谚攒,或者調(diào)用kill -9 命令殺死redis的時候,使用rdb的方式持久化是不夠氛堕,這個時候最新的操作是沒有被持久化馏臭。因此redis提供另外的一種持久化方式,append-only file 讼稚。

1.3.1 AOF 配置方式

要啟動AOF的方式括儒,需要在配置文件中設(shè)置

appendonly yes

配置時候,redis沒產(chǎn)生一條指令都會被追加到AOF文件中锐想,當服務(wù)器重啟的時候帮寻,redis就從這個文件中重新執(zhí)行指令來回復(fù)數(shù)據(jù)到內(nèi)存中。

aof重寫

通過上面不難發(fā)現(xiàn)痛倚,如果每次執(zhí)行指令被保存规婆,aof文件會越來遠大。例如,一個increment 100次抒蚜,就有100條指令掘鄙,但是實際可以在回復(fù)數(shù)據(jù)的時候調(diào)用一句set 指令回復(fù)到最后的數(shù)據(jù)就可以了。所以redis也內(nèi)置了重寫機制嗡髓。在不中斷對客戶端的服務(wù)器的情況下操漠,在后臺對aof文件重寫。reids 2.2之前饿这。需要是不是的調(diào)用BGREWRIETAOF指令浊伙,redis 2.4之后都是自動觸發(fā)此指令。

同步頻率配置 (how durable)

多久把數(shù)據(jù)同步(fsync)一次到文件的策略有三種:

  1. fsync always 每次新的指令长捧,每條指令都加到aof嚣鄙。此方法非常非常的慢,但是非常安全串结。
  2. fsync everysec每個一秒鐘同步一次哑子。這種方法速度很快,最壞情況是損失1s內(nèi)的數(shù)據(jù)
  3. never no 不同步肌割,而是交給操作系統(tǒng)去處理卧蜓。非常快把敞,但是不安全弥奸。

redis默認和推薦的方法是每秒同步方式。

配置方式

# appendfsync always
appendfsync everysec
# appendfsync no

AOF文件損壞怎么處理

當AOF文件損壞的時候奋早,redis不能再從AOF中恢復(fù)數(shù)據(jù)盛霎,可按找下面的步驟處理:

  1. 備份當前AOF文件
  2. 使用redis-check-aof工具修復(fù)原AOF文件,執(zhí)行命令 redis-check-aof --fix
  3. 選擇性的使用diff -u檢測兩個文件的不同
  4. 用修改后的文件重啟服務(wù)

1.3.2 AOF 工作原理(rewrite)

  1. redis forks 一個子進程
  2. 子進程開始把AOF寫到一個臨時文件
  3. 父進程計算所有的新變化并放在一個內(nèi)存緩沖區(qū)(同時他還把這些變化寫進老的AOF文件伸蚯,所以重寫失敗摩渺,也是安全的)
  4. 最后。redis自動用新文件替換老文件剂邮。開始往新文件添加數(shù)據(jù)

1.3.3 AOF 優(yōu)缺點

AOF 優(yōu)點

  1. 數(shù)據(jù)安全性更高,從同步機制上看横侦。always方式滿挥萌,但每條指令都存儲。
  2. aof是一個追加文件枉侧,出現(xiàn)問題可以使用redis-check-aof工具修復(fù)
  3. 文件過大的時候會使用重寫方式引瀑,只要文件存在,數(shù)據(jù)有可以恢復(fù)
  4. 文件內(nèi)容以redis的協(xié)議存儲榨馁,方便解讀憨栽。能偶方便導(dǎo)出和解析。

AOF 缺點

  1. 數(shù)據(jù)量過大的時候,redis的aof體積會比rdb文件大
  2. 根據(jù)所使用的 fsync 策略屑柔,AOF 的速度可能會慢于 RDB 屡萤。 在一般情況下, 每秒 fsync 的性能依然非常高掸宛, 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快死陆, 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時唧瘾,RDB 可以提供更有保證的最大延遲時間(latency)

1.4 數(shù)據(jù)容災(zāi)

需要經(jīng)常對數(shù)據(jù)數(shù)據(jù)(rdb文件)進行備份

  1. 使用corn job方式措译,定去備份rdb文件到某個文件夾
  2. 備份時間打上時間標簽,使用find找到很早期的備份刪除
  3. 定期把備份放到當前物理機之外的機器備份一份饰序。
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末领虹,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子求豫,更是在濱河造成了極大的恐慌掠械,老刑警劉巖,帶你破解...
    沈念sama閱讀 206,126評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件注祖,死亡現(xiàn)場離奇詭異猾蒂,居然都是意外死亡,警方通過查閱死者的電腦和手機是晨,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,254評論 2 382
  • 文/潘曉璐 我一進店門肚菠,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人罩缴,你說我怎么就攤上這事蚊逢。” “怎么了箫章?”我有些...
    開封第一講書人閱讀 152,445評論 0 341
  • 文/不壞的土叔 我叫張陵烙荷,是天一觀的道長。 經(jīng)常有香客問我檬寂,道長终抽,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 55,185評論 1 278
  • 正文 為了忘掉前任桶至,我火速辦了婚禮昼伴,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘镣屹。我一直安慰自己圃郊,他們只是感情好,可當我...
    茶點故事閱讀 64,178評論 5 371
  • 文/花漫 我一把揭開白布女蜈。 她就那樣靜靜地躺著持舆,像睡著了一般色瘩。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上逸寓,一...
    開封第一講書人閱讀 48,970評論 1 284
  • 那天居兆,我揣著相機與錄音,去河邊找鬼席覆。 笑死史辙,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的佩伤。 我是一名探鬼主播聊倔,決...
    沈念sama閱讀 38,276評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼生巡!你這毒婦竟也來了耙蔑?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 36,927評論 0 259
  • 序言:老撾萬榮一對情侶失蹤孤荣,失蹤者是張志新(化名)和其女友劉穎甸陌,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體盐股,經(jīng)...
    沈念sama閱讀 43,400評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡钱豁,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,883評論 2 323
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了疯汁。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片牲尺。...
    茶點故事閱讀 37,997評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖幌蚊,靈堂內(nèi)的尸體忽然破棺而出谤碳,到底是詐尸還是另有隱情,我是刑警寧澤溢豆,帶...
    沈念sama閱讀 33,646評論 4 322
  • 正文 年R本政府宣布蜒简,位于F島的核電站,受9級特大地震影響漩仙,放射性物質(zhì)發(fā)生泄漏搓茬。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,213評論 3 307
  • 文/蒙蒙 一讯赏、第九天 我趴在偏房一處隱蔽的房頂上張望垮兑。 院中可真熱鬧,春花似錦漱挎、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,204評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽私爷。三九已至,卻和暖如春膊夹,著一層夾襖步出監(jiān)牢的瞬間衬浑,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,423評論 1 260
  • 我被黑心中介騙來泰國打工放刨, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留工秩,地道東北人。 一個月前我還...
    沈念sama閱讀 45,423評論 2 352
  • 正文 我出身青樓进统,卻偏偏與公主長得像助币,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子螟碎,可洞房花燭夜當晚...
    茶點故事閱讀 42,722評論 2 345

推薦閱讀更多精彩內(nèi)容