主頁 > 知識庫 > redis的2種持久化方案深入講解

redis的2種持久化方案深入講解

熱門標(biāo)簽:一個地圖標(biāo)注多少錢 四川穩(wěn)定外呼系統(tǒng)軟件 廊坊外呼系統(tǒng)在哪買 高碑店市地圖標(biāo)注app 南京手機外呼系統(tǒng)廠家 臺灣電銷 b2b外呼系統(tǒng) 地圖標(biāo)注工廠入駐 400電話辦理的口碑

前言

Redis是一種高級key-value數(shù)據(jù)庫。它跟memcached類似,不過數(shù)據(jù)可以持久化,而且支持的數(shù)據(jù)類型很豐富。有字符串,鏈表,集 合和有序集合。支持在服務(wù)器端計算集合的并,交和補集(difference)等,還支持多種排序功能。所以Redis也可以被看成是一個數(shù)據(jù)結(jié)構(gòu)服務(wù) 器。

Redis的所有數(shù)據(jù)都是保存在內(nèi)存中,然后不定期的通過異步方式保存到磁盤上(這稱為“半持久化模式”);也可以把每一次數(shù)據(jù)變化都寫入到一個append only file(aof)里面(這稱為“全持久化模式”)。

人生在于折騰系列,網(wǎng)絡(luò),多線程等系列博客樓主還在繼續(xù)折騰也不會放棄。這是全新的系列,緩存的知識其實并不僅僅在于簡單的增刪改查,我覺得有必要全面深入的學(xué)習(xí)一波。記錄學(xué)習(xí)的過程與體悟。

RDB

什么是RDB

對redis中的數(shù)據(jù)執(zhí)行周期性的持久化,通過配置文件中設(shè)置檢查間隔時間與備份觸發(fā)條件來對數(shù)據(jù)進行周期性的持久化

RDB持久化的優(yōu)點

  • RDB會生成多個數(shù)據(jù)文件,每個數(shù)據(jù)文件都代表了某一個時刻中redis的數(shù)據(jù),這種多個數(shù)據(jù)文件的方式,非常適合做冷備份。
  • RDB對redis對外提供的讀寫服務(wù),影響非常小,可以讓redis保持高性能,因為redis主進程只需要fork一個子進程,讓子進程執(zhí)行磁盤IO操作來進行RDB持久化即可
  • 相對于AOF持久化機制來說,直接基于RDB數(shù)據(jù)文件來重啟和恢復(fù)redis進程,更加快速

RDB持久化的缺點

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

如何配置redis的RDB持久化

redis.conf文件,去配置持久化

save 60 1000

每隔60s,如果有超過1000個key發(fā)生了變更,那么就生成一個新的dump.rdb文件,就是當(dāng)前redis內(nèi)存中完整的數(shù)據(jù)快照,這個操作也被稱之為snapshotting,快照

也可以手動調(diào)用save或者bgsave命令,同步或異步執(zhí)行rdb快照生成。(save在生成dump.rdb文件的時候redis主線程將會被阻塞,bgsave則不會阻塞redis主線程)

save可以設(shè)置多個,就是多個snapshotting檢查點,每到一個檢查點,就會去check一下,是否有指定的key數(shù)量發(fā)生了變更,如果有,就生成一個新的dump.rdb文件

AOF

什么AOF

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

AOF持久化的優(yōu)點

  1. AOF可以更好的保護數(shù)據(jù)不丟失,一般AOF會每隔1秒,通過一個后臺線程執(zhí)行一次fsync操作(fsync的功能是確保所有已修改的內(nèi)容已經(jīng)正確同步到硬盤上,該調(diào)用會阻塞等待直到設(shè)備報告IO完成。),最多丟失1秒鐘的數(shù)據(jù)每隔1秒,就執(zhí)行一次fsync操作,保證oscache中的數(shù)據(jù)寫入磁盤中redis進程掛了,最多丟掉1秒鐘的數(shù)據(jù)。
  2. AOF日志文件以append-only模式寫入,所以沒有任何磁盤尋址的開銷,寫入性能非常高,而且文件不容易破損,即使文件尾部破損,也很容易修復(fù)。
  3. AOF日志文件即使過大的時候,出現(xiàn)后臺重寫操作,也不會影響客戶端的讀寫。因為在rewritelog的時候,會對其中的指導(dǎo)進行壓縮,創(chuàng)建出一份需要恢復(fù)數(shù)據(jù)的最小日志出來。再創(chuàng)建新日志文件的時候,老的日志文件還是照常寫入。當(dāng)新的merge后的日志文件ready的時候,再交換新老日志文件即可。
  4. AOF日志文件的命令通過非常可讀的方式進行記錄,這個特性非常適合做災(zāi)難性的誤刪除的緊急恢復(fù)。比如某人不小心用flushall命令清空了所有數(shù)據(jù),只要這個時候后臺rewrite還沒有發(fā)生,那么就可以立即拷貝AOF文件,將最后一條flushall命令給刪了,然后再將該AOF文件放回去,就可以通過恢復(fù)機制,自動恢復(fù)所有數(shù)據(jù)。

AOF持久化機制的缺點

  1. 對于同一份數(shù)據(jù)來說,AOF日志文件通常比RDB數(shù)據(jù)快照文件更大。
  2. AOF開啟后,支持的寫QPS會比RDB支持的寫QPS低,因為AOF一般會配置成每秒fsync一次日志文件。盡管每秒一次fsync,性能也還是很高的,如果你要保證一條數(shù)據(jù)都不丟,也是可以的,AOF的fsync設(shè)置成沒寫入一條數(shù)據(jù),fsync一次,那就完蛋了,redis的QPS將會更低。
  3. 以前AOF發(fā)生過bug,就是通過AOF記錄的日志,進行數(shù)據(jù)恢復(fù)的時候,沒有恢復(fù)一模一樣的數(shù)據(jù)出來。所以說,類似AOF這種較為復(fù)雜的基于命令日志/merge/回放的方式,比基于RDB每次持久化一份完整的數(shù)據(jù)快照文件的方式,更加脆弱一些,容易有bug。不過AOF就是為了避免rewrite過程導(dǎo)致的bug,因此每次rewrite并不是基于舊的指令日志進行merge的,而是基于當(dāng)時內(nèi)存中的數(shù)據(jù)進行指令的重新構(gòu)建,這樣健壯性會好很多。
  4. 唯一的比較大的缺點,其實就是做數(shù)據(jù)恢復(fù)的時候,會比較慢,還有做冷備,定期的備份,不太方便,可能要自己手寫復(fù)雜的腳本去做,做冷備不太合適。RDB恢復(fù)日志,就是一份數(shù)據(jù)文件,恢復(fù)的時候,直接加載到內(nèi)存中即可。而AOF則不同,做數(shù)據(jù)恢復(fù)的時候,其實是要回放和執(zhí)行所有的指令日志,來恢復(fù)出來內(nèi)存中的所有數(shù)據(jù)的。

如何配置redis的AOF持久化

AOF持久化,默認(rèn)是關(guān)閉的,默認(rèn)是打開RDB持久化

appendonly yes,可以打開AOF持久化機制,在生產(chǎn)環(huán)境里面,一般來說AOF都是要打開的,除非你說隨便丟個幾分鐘的數(shù)據(jù)也無所謂。打開AOF持久化機制之后,redis每次接收到一條寫命令,就會寫入日志文件中,當(dāng)然是先寫入os cache的,然后每隔一定時間再fsync一下。

如果AOF和RDB都開啟了,redis重啟的時候,優(yōu)先通過AOF進行數(shù)據(jù)恢復(fù)的,因為aof數(shù)據(jù)比較完整

可以配置AOF的fsync策略,有以下三種策略可以選擇:

  • always: 每次寫入一條數(shù)據(jù),立即將這個數(shù)據(jù)對應(yīng)的寫日志fsync到磁盤上去,性能非常非常差,吞吐量很低; 確保說redis里的數(shù)據(jù)一條都不丟,那就只能這樣了
  • everysec: 每秒將os cache中的數(shù)據(jù)fsync到磁盤,這個最常用的,生產(chǎn)環(huán)境一般都這么配置,性能很高,QPS還是可以上萬的
  • no: 僅僅redis負(fù)責(zé)將數(shù)據(jù)寫入os cache就撒手不管了,然后后面os自己會時不時有自己的策略將數(shù)據(jù)刷入磁盤,不可控了

總結(jié)

以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,謝謝大家對腳本之家的支持。

您可能感興趣的文章:
  • Redis為什么快如何實現(xiàn)高可用及持久化
  • docker下的 redis 之持久化存儲詳解
  • Linux下redis的持久化、主從同步與哨兵詳解
  • 淺談redis內(nèi)存數(shù)據(jù)的持久化方式
  • Redis兩種持久化方案RDB和AOF詳解
  • Redis持久化深入詳解

標(biāo)簽:南寧 畢節(jié) 河源 甘南 拉薩 伊春 泰州 定州

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《redis的2種持久化方案深入講解》,本文關(guān)鍵詞  redis,的,2種,持久化,方案,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《redis的2種持久化方案深入講解》相關(guān)的同類信息!
  • 本頁收集關(guān)于redis的2種持久化方案深入講解的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章