redis數(shù)據(jù)的兩種持久化方式對(duì)比
一.概念介紹
redis提供了兩種持久化的方式,分別是RDB(Redis DataBase)和AOF(Apend Only File)。
RDB方式
RDB方式是一種快照式的持久化方法,將某一時(shí)刻的數(shù)據(jù)持久化到磁盤中。
•redis在進(jìn)行數(shù)據(jù)持久化的過程中,會(huì)先將數(shù)據(jù)寫入到一個(gè)臨時(shí)文件中,待持久化過程都結(jié)束了,才會(huì)用這個(gè)臨時(shí)文件替換上次持久化好的文件。正是這種特性,讓我們可以隨時(shí)來進(jìn)行備份,因?yàn)榭煺瘴募偸峭暾捎玫摹?br />
•對(duì)于RDB方式,redis會(huì)單獨(dú)創(chuàng)建(fork)一個(gè)子進(jìn)程來進(jìn)行持久化,而主進(jìn)程是不會(huì)進(jìn)行任何IO操作的,這樣就確保了redis極高的性能。
•如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù),且對(duì)于數(shù)據(jù)恢復(fù)的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。
AOF方式
AOF方式是將執(zhí)行過的寫指令記錄下來,在數(shù)據(jù)恢復(fù)時(shí)按照叢前到后的順序再將指令執(zhí)行一遍。
•AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾.Redis還能對(duì)AOF文件進(jìn)行后臺(tái)重寫,使得AOF文件的體積不至于過大.默認(rèn)的AOF持久化策略是每秒鐘fsync一次(fsync是指把緩存中的寫指令記錄到磁盤中),因?yàn)樵谶@種情況下,redis仍然可以保持很好的處理性能,即使redis故障,也只會(huì)丟失最近1秒鐘的數(shù)據(jù)。
•如果在追加日志時(shí),恰好遇到磁盤空間滿、inode滿或斷電等情況導(dǎo)致日志寫入不完整,也沒有關(guān)系,redis提供了redis-check-aof工具,可以用來進(jìn)行日志修復(fù)。
•因?yàn)椴捎昧俗芳臃绞?,如果不做任何處理的話,AOF文件會(huì)變得越來越大,為此,redis提供了AOF文件重寫(rewrite)機(jī)制,即當(dāng)AOF文件的大小超過所設(shè)定的閾值時(shí),redis就會(huì)啟動(dòng)AOF文件的內(nèi)容壓縮,只保留可以恢復(fù)數(shù)據(jù)的最小指令集。舉個(gè)例子或許更形象,假如我們調(diào)用了100次INCR指令,在AOF文件中就要存儲(chǔ)100條指令,但這明顯是很低效的,完全可以把這100條指令合并成一條SET指令,這就是重寫機(jī)制的原理。
•在進(jìn)行AOF重寫時(shí),仍然是采用先寫臨時(shí)文件,全部完成后再替換的流程,所以斷電、磁盤滿等問題都不會(huì)影響AOF文件的可用性。
二. 兩種方式優(yōu)缺點(diǎn)
1. RDB方式
•優(yōu)點(diǎn):
1.RDB是一個(gè)單一的緊湊文件,它保存了某個(gè)時(shí)間點(diǎn)得數(shù)據(jù)集,非常適用于數(shù)據(jù)集的備份,比如你可以在每個(gè)小時(shí)報(bào)保存一下過去24小時(shí)內(nèi)的數(shù)據(jù),同時(shí)每天保存過去30天的數(shù)據(jù),這樣即使出了問題你也可以根據(jù)需求恢復(fù)到不同版本的數(shù)據(jù)集.
2.RDB是一個(gè)緊湊的單一文件,方便傳送,適用于災(zāi)難恢復(fù).
3.RDB在保存RDB文件時(shí)父進(jìn)程唯一需要做的就是fork出一個(gè)子進(jìn)程,接下來的工作全部由子進(jìn)程來做,父進(jìn)程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能.
4.與AOF相比,在恢復(fù)大的數(shù)據(jù)集的時(shí)候,RDB方式會(huì)更快一些.
•缺點(diǎn):
1.Redis意外宕機(jī),可能會(huì)丟失幾分鐘的數(shù)據(jù)(取決于配置的save時(shí)間點(diǎn))。RDB方式需要保存珍整個(gè)數(shù)據(jù)集,是一個(gè)比較繁重的工作,通常需要設(shè)置5分鐘或者更久做一次完整的保存。
2.RDB 需要經(jīng)常fork子進(jìn)程來保存數(shù)據(jù)集到硬盤上,當(dāng)數(shù)據(jù)集比較大的時(shí)候,fork的過程是非常耗時(shí)的,可能會(huì)導(dǎo)致Redis在一些毫秒級(jí)內(nèi)不能響應(yīng)客戶端的請(qǐng)求.如果數(shù)據(jù)集巨大并且CPU性能不是很好的情況下,這種情況會(huì)持續(xù)更久。
2. AOF方式
•優(yōu)點(diǎn)
1.使用AOF 會(huì)讓Redis數(shù)據(jù)更加耐久: 你可以使用不同的fsync策略:無fsync,每秒fsync,每次寫的時(shí)候fsync.使用默認(rèn)的每秒fsync策略,Redis的性能依然很好(fsync是由后臺(tái)線程進(jìn)行處理的,主線程會(huì)盡力處理客戶端請(qǐng)求),一旦出現(xiàn)故障,你最多丟失1秒的數(shù)據(jù).
2.AOF文件是一個(gè)只進(jìn)行追加的日志文件,所以不需要寫入seek,即使由于某些原因(磁盤空間已滿,寫的過程中宕機(jī)等等)未執(zhí)行完整的寫入命令,你也也可使用redis-check-aof工具修復(fù)這些問題.
3.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)行追加操作。
4.AOF 文件有序地保存了對(duì)數(shù)據(jù)庫執(zhí)行的所有寫入操作, 這些寫入操作以 Redis 協(xié)議的格式保存, 因此 AOF 文件的內(nèi)容非常容易被人讀懂, 對(duì)文件進(jìn)行分析也很輕松。 導(dǎo)出AOF 文件也非常簡(jiǎn)單: 舉個(gè)例子, 如果你不小心執(zhí)行了 FLUSHALL 命令, 但只要 AOF 文件未被重寫, 那么只要停止服務(wù)器, 移除 AOF 文件末尾的 FLUSHALL 命令, 并重啟 Redis , 就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。
•缺點(diǎn)
1.對(duì)于相同的數(shù)據(jù)集來說,AOF 文件的體積通常要大于 RDB 文件的體積。
2.根據(jù)所使用的 fsync 策略,AOF 的速度可能會(huì)慢于 RDB 。 在一般情況下, 每秒 fsync 的性能依然非常高, 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快, 即使在高負(fù)荷之下也是如此。 不過在處理巨大的寫入載入時(shí),RDB 可以提供更有保證的最大延遲時(shí)間。
三. 配置方式
1. RDB配置方式
默認(rèn)情況下,是快照rdb的持久化方式,將內(nèi)存中的數(shù)據(jù)以快照的方式寫入二進(jìn)制文件中,默認(rèn)的文件名是dump.rdb
redis.conf配置:
save 900 1 save 300 10 save 60 10000
以上是默認(rèn)配置:900秒之內(nèi),如果超過1個(gè)key被修改,則發(fā)起快照保存;
300秒內(nèi),如果超過10個(gè)key被修改,則發(fā)起快照保存 ;
1分鐘之內(nèi),如果1萬個(gè)key被修改,則發(fā)起快照保存 ;
這種方式不能完全保證數(shù)據(jù)持久化,因?yàn)槭嵌〞r(shí)保存,所以當(dāng)redis服務(wù)down掉,就會(huì)丟失一部分?jǐn)?shù)據(jù),而且數(shù)據(jù)量大,寫操作多的情況下,會(huì)引起大量的磁盤IO操作,會(huì)影響性能。
所以,如果這兩種方式同時(shí)開啟,如果對(duì)數(shù)據(jù)進(jìn)行恢復(fù),不應(yīng)該用rdb持久化方式對(duì)數(shù)據(jù)庫進(jìn)行恢復(fù)。
2. AOF 配置方式
使用aof做持久化,每一個(gè)寫命令都通過write函數(shù)追加到appendonly.aof中.
配置方式:?jiǎn)?dòng)aof持久化的方式
appendonly yes
相關(guān)文章
Redis實(shí)現(xiàn)單設(shè)備登錄的場(chǎng)景分析
這篇文章主要介紹了Redis實(shí)現(xiàn)單設(shè)備登錄,用戶首次登錄時(shí),將用戶信息存入Redis,key是用戶id,value是token,當(dāng)用戶在其他設(shè)備登錄時(shí),會(huì)重新生成token,這個(gè)時(shí)候原先的token已經(jīng)被覆蓋了,本文給大家提供樣例及核心代碼,感興趣的朋友參考下吧2022-04-04
Redis 緩存實(shí)現(xiàn)存儲(chǔ)和讀取歷史搜索關(guān)鍵字的操作方法
這篇文章主要介紹了Redis 緩存實(shí)現(xiàn)存儲(chǔ)和讀取歷史搜索關(guān)鍵字,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-12-12
Linux下安裝Redis 6.0.5的實(shí)現(xiàn)
本文詳細(xì)介紹了在Linux系統(tǒng)下安裝Redis 6.0.5的步驟,包括安裝準(zhǔn)備、編譯安裝、啟動(dòng)服務(wù)、設(shè)置密碼和配置文件修改等,具有一定的參考價(jià)值,感興趣的可以了解一下2025-02-02
關(guān)于Redis?bigkeys命令會(huì)阻塞問題的解決
這篇文章主要介紹了關(guān)于Redis?bigkeys命令會(huì)阻塞問題的解決,今天分享一次Redis引發(fā)的線上事故,避免再次踩雷,實(shí)現(xiàn)快速入門,需要的朋友可以參考下2023-03-03
redis實(shí)現(xiàn)sentinel哨兵架構(gòu)的方法
哨兵是一個(gè)分布式系統(tǒng),可以在一個(gè)架構(gòu)中運(yùn)行多個(gè)哨兵(sentinel) 進(jìn)程,這些進(jìn)程使用流言協(xié)議(gossip protocols)來接收關(guān)于Master主服務(wù)器是否下線的信息,這篇文章主要介紹了redis實(shí)現(xiàn)sentinel哨兵架構(gòu),需要的朋友可以參考下2022-11-11
redis 存儲(chǔ)對(duì)象的方法對(duì)比分析
這篇文章主要介紹了redis 存儲(chǔ)對(duì)象的方法對(duì)比分析,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-07-07
Redis中主鍵失效的原理及實(shí)現(xiàn)機(jī)制剖析
這篇文章主要介紹了Redis中主鍵失效的原理及實(shí)現(xiàn)機(jī)制剖析,本文講解了失效時(shí)間的控制、失效的內(nèi)部實(shí)現(xiàn)、Memcached 刪除失效主鍵的方法與 Redis 有何異同、Redis 的主鍵失效機(jī)制會(huì)不會(huì)影響系統(tǒng)性能等內(nèi)容,需要的朋友可以參考下2015-06-06

