Redis持久化深入詳解
1、概述
Redis 是內(nèi)存數(shù)據(jù)庫(kù),如果不能將內(nèi)存中的數(shù)據(jù)保存到磁盤(pán)中,那么一旦服務(wù)器進(jìn)程退出,服務(wù)器的數(shù)據(jù)庫(kù)數(shù)據(jù)也會(huì)消失,所以Redis提供了持久化的功能,redis分為兩種持久化方式:RDB和AOF。有以下幾個(gè)特點(diǎn):
1.RDB持久化方式能夠在指定的時(shí)間間隔能對(duì)你的數(shù)據(jù)進(jìn)行快照存儲(chǔ)。
2.AOF持久化方式記錄每次對(duì)服務(wù)器寫(xiě)的操作,當(dāng)服務(wù)器重啟的時(shí)候會(huì)重新執(zhí)行這些命令來(lái)恢復(fù)原始的數(shù)據(jù),AOF命令以redis協(xié)議追加保存每次寫(xiě)的操作到文件末尾。Redis還能對(duì)AOF文件后臺(tái)重寫(xiě),使得AOF文件的體積不至于過(guò)大。
3.如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在,你也可以不使用任何持久化的方式。
4.你也可以同時(shí)開(kāi)啟兩種持久化方式,在這種情況下,當(dāng)redis重啟的時(shí)候會(huì)優(yōu)先載入AOF文件來(lái)恢復(fù)原始的數(shù)據(jù)。因?yàn)樵谕ǔG闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。
2、RDB
1、概念
在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫(xiě)入磁盤(pán)中,它恢復(fù)的時(shí)候是將快照中的文件直接讀取到內(nèi)存中。
2、持久化機(jī)制-BGSAVE

通常,會(huì)立即返回ok,Redis進(jìn)程會(huì)執(zhí)行fork操作創(chuàng)建子進(jìn)程,Redis在fork時(shí),父進(jìn)程會(huì)繼續(xù)為客戶端提供服務(wù),子進(jìn)程會(huì)將數(shù)據(jù)持久化到硬盤(pán)上,然后退出。如果已經(jīng)在后臺(tái)執(zhí)行保存或者正在運(yùn)行另一個(gè)非后臺(tái)保存的進(jìn)程,特別是正在進(jìn)行AOF寫(xiě)入時(shí),則會(huì)返回錯(cuò)誤。如果使用了bgsave任務(wù),而正在進(jìn)行AOF寫(xiě)入時(shí),該命令將立即返回ok,并計(jì)劃在下一次機(jī)會(huì)運(yùn)行后臺(tái)保存。阻塞只會(huì)在fork階段。
客戶端可以使用lastsave命令檢查操作是否成功。
3、持久化機(jī)制-SAVE
不會(huì)接受客戶端執(zhí)行的操作命令,等持久化工作完成之后,會(huì)將新的文件替換舊的文件。
4、持久化機(jī)制-自動(dòng)觸發(fā)
在redis.conf中可以配置,讓用戶自定義save屬性,讓服務(wù)器每一段時(shí)間內(nèi)執(zhí)行一次bgsave操作。
# 服務(wù)器在900秒內(nèi),對(duì)數(shù)據(jù)庫(kù)進(jìn)行了至少1次修改 save 900 1 # 服務(wù)器在300秒內(nèi),對(duì)數(shù)據(jù)庫(kù)進(jìn)行了至少10次修改 save 300 10 # 服務(wù)器在60秒內(nèi),對(duì)數(shù)據(jù)庫(kù)進(jìn)行了至少10000次修改 save 60 10000 # bgsave發(fā)生錯(cuò)誤時(shí)是否停止寫(xiě)入,一般為yes stop-writes-on-bgsave-error yes # 持久化時(shí)是否使用LZF壓縮字符串對(duì)象? rdbcompression yes # 是否對(duì)rdb文件進(jìn)行校驗(yàn)和檢驗(yàn),通常為yes rdbchecksum yes # RDB持久化文件名 dbfilename dump.rdb # 持久化文件存儲(chǔ)目錄 dir ./
5、恢復(fù)數(shù)據(jù)機(jī)制
只需要將rdb文件放在我們r(jià)edis啟動(dòng)目錄就可以了,redis啟動(dòng)的時(shí)候會(huì)自動(dòng)檢查文件并恢復(fù)其中的數(shù)據(jù)。
6、優(yōu)點(diǎn)
- RDB是一個(gè)非常緊湊的文件,它保存了某個(gè)時(shí)間點(diǎn)得數(shù)據(jù)集,非常適用于數(shù)據(jù)集的備份,比如你可以在每個(gè)小時(shí)報(bào)保存一下過(guò)去24小時(shí)內(nèi)的數(shù)據(jù),同時(shí)每天保存過(guò)去30天的數(shù)據(jù),這樣即使出了問(wèn)題你也可以根據(jù)需求恢復(fù)到不同版本的數(shù)據(jù)集。
- RDB是一個(gè)緊湊的單一文件,很方便傳送到另一個(gè)遠(yuǎn)端數(shù)據(jù)中心或者亞馬遜的S3(可能加密),非常適用于災(zāi)難恢復(fù)。
- RDB在保存RDB文件時(shí)父進(jìn)程唯一需要做的就是fork出一個(gè)子進(jìn)程,接下來(lái)的工作全部由子進(jìn)程來(lái)做,父進(jìn)程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能。
- 與AOF相比,在恢復(fù)大的數(shù)據(jù)集的時(shí)候,RDB方式會(huì)更快一些。
7、缺點(diǎn)
- 如果你希望在redis意外停止工作(例如電源中斷)的情況下丟失的數(shù)據(jù)最少的話,那么RDB不適合你。雖然你可以配置不同的save時(shí)間點(diǎn)(例如每隔5分鐘并且對(duì)數(shù)據(jù)集有100個(gè)寫(xiě)的操作),是Redis要完整的保存整個(gè)數(shù)據(jù)集是一個(gè)比較繁重的工作,你通常會(huì)每隔5分鐘或者更久做一次完整的保存,萬(wàn)一在Redis意外宕機(jī),你可能會(huì)丟失幾分鐘的數(shù)據(jù)。
- RDB 需要經(jīng)常fork子進(jìn)程來(lái)保存數(shù)據(jù)集到硬盤(pán)上,當(dāng)數(shù)據(jù)集比較大的時(shí)候,fork的過(guò)程是非常耗時(shí)的,可能會(huì)導(dǎo)致Redis在一些毫秒級(jí)內(nèi)不能響應(yīng)客戶端的請(qǐng)求。如果數(shù)據(jù)集巨大并且CPU性能不是很好的情況下,這種情況會(huì)持續(xù)1秒,AOF也需要fork,但是你可以調(diào)節(jié)重寫(xiě)日志文件的頻率來(lái)提高數(shù)據(jù)集的耐久度。
3、AOF
1、概念
以日志的形式來(lái)記錄每個(gè)寫(xiě)操作,將Redis執(zhí)行過(guò)的所有指令記錄下來(lái)(讀操作不記錄),只許追加文件但不可以改寫(xiě)文件,Redis啟動(dòng)之初會(huì)讀取該文件重新構(gòu)建數(shù)據(jù),換言之,Redis重啟的話就會(huì)根據(jù)日志文件的內(nèi)容將寫(xiě)的指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。
2、持久化原理
所有操作的命令會(huì)追加在文件中。
3、開(kāi)啟AOF持久化
# 開(kāi)啟aof持久化方式,默認(rèn)no appendonly no # aof 持久化生成的文件名稱 appendfilename "appendonly.aof" # 三種持久化機(jī)制 # appendfsync always appendfsync everysec # appendfsync no
4、三種觸發(fā)持久化機(jī)制
- always
同步持久化,每次發(fā)生數(shù)據(jù)變更會(huì)被立即持久化到硬盤(pán)中,性能比較差,但是數(shù)據(jù)完整性好。
- everysec
異步操作,每秒持久化數(shù)據(jù)到硬盤(pán)一次,可能會(huì)丟失一秒的數(shù)據(jù)。
- no
從不持久化到硬盤(pán)。
5、AOF文件損壞
如果 aof 文件被破壞,redis服務(wù)是啟動(dòng)不了的。redis本身提供了修復(fù)了工具。redis-check-aof --fix appendonly.aof
5、優(yōu)點(diǎn)
- 根據(jù)配置不同的策略,讓你選擇持久化的方式。
- AOF文件是一個(gè)只進(jìn)行追加的日志文件,所以不需要寫(xiě)入seek,即使由于某些原因(磁盤(pán)空間已滿,寫(xiě)的過(guò)程中宕機(jī)等等)未執(zhí)行完整的寫(xiě)入命令,你也也可使用redis-check-aof工具修復(fù)這些問(wèn)題。
- Redis 可以在 AOF 文件體積變得過(guò)大時(shí),自動(dòng)地在后臺(tái)對(duì) AOF 進(jìn)行重寫(xiě): 重寫(xiě)后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。 整個(gè)重寫(xiě)操作是絕對(duì)安全的,因?yàn)?Redis 在創(chuàng)建新 AOF 文件的過(guò)程中,會(huì)繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面,即使重寫(xiě)過(guò)程中發(fā)生停機(jī),現(xiàn)有的 AOF 文件也不會(huì)丟失。 而一旦新 AOF 文件創(chuàng)建完畢,Redis 就會(huì)從舊 AOF 文件切換到新 AOF 文件,并開(kāi)始對(duì)新 AOF 文件進(jìn)行追加操作。
- AOF 文件有序地保存了對(duì)數(shù)據(jù)庫(kù)執(zhí)行的所有寫(xiě)入操作,這些寫(xiě)入操作以 Redis 協(xié)議的格式保存, 因此 AOF 文件的內(nèi)容非常容易被人讀懂,對(duì)文件進(jìn)行分析(parse)也很輕松。導(dǎo)出(export)AOF文件也非常簡(jiǎn)單:舉個(gè)例子, 如果你不小心執(zhí)行了 FLUSHALL 命令, 但只要 AOF 文件未被重寫(xiě),那么只要停止服務(wù)器,移除 AOF 文件末尾的 FLUSHALL 命令,并重啟 Redis,就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。
6、缺點(diǎn)
- 對(duì)于相同的數(shù)據(jù)集來(lái)說(shuō),AOF 文件的體積通常要大于 RDB 文件的體積。
- 根據(jù)所使用的 fsync 策略,AOF 的速度可能會(huì)慢于 RDB 。 在一般情況下, 每秒 fsync 的性能依然非常高, 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快, 即使在高負(fù)荷之下也是如此。 不過(guò)在處理巨大的寫(xiě)入載入時(shí),RDB 可以提供更有保證的最大延遲時(shí)間(latency)。
4、如何選擇持久化機(jī)制
開(kāi)啟兩種持久化方式,根據(jù)自己的業(yè)務(wù)需求針對(duì)redis進(jìn)行配置的調(diào)整。
到此這篇關(guān)于Redis持久化深入詳解的文章就介紹到這了,更多相關(guān)Redis持久化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
詳解redis在服務(wù)器linux下啟動(dòng)的相關(guān)命令(安裝和配置)
這篇文章主要介紹了redis在服務(wù)器linux下的啟動(dòng)的相關(guān)命令(安裝和配置),本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-08-08
Window server中安裝Redis的超詳細(xì)教程
這篇文章主要介紹了Window server中安裝Redis的教程,本文通過(guò)圖文實(shí)例代碼相結(jié)合給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2021-11-11
redis實(shí)現(xiàn)sentinel哨兵架構(gòu)的方法
哨兵是一個(gè)分布式系統(tǒng),可以在一個(gè)架構(gòu)中運(yùn)行多個(gè)哨兵(sentinel) 進(jìn)程,這些進(jìn)程使用流言協(xié)議(gossip protocols)來(lái)接收關(guān)于Master主服務(wù)器是否下線的信息,這篇文章主要介紹了redis實(shí)現(xiàn)sentinel哨兵架構(gòu),需要的朋友可以參考下2022-11-11
Windows安裝Redis并添加本地自啟動(dòng)服務(wù)的實(shí)例詳解
這篇文章主要介紹了Windows安裝Redis并添加本地自啟動(dòng)服務(wù)的實(shí)例詳解,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-11-11
Centos7 Redis主從搭建配置的實(shí)現(xiàn)
這篇文章主要介紹了Centos7 Redis主從搭建配置的實(shí)現(xiàn),小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2018-06-06
如何基于Session實(shí)現(xiàn)短信登錄功能
對(duì)比起Cookie,Session是存儲(chǔ)在服務(wù)器端的會(huì)話,相對(duì)安全,并且不像Cookie那樣有存儲(chǔ)長(zhǎng)度限制,下面這篇文章主要給大家介紹了關(guān)于如何基于Session實(shí)現(xiàn)短信登錄功能的相關(guān)資料,需要的朋友可以參考下2022-10-10

