網(wǎng)站建設(shè)模板一次收費(fèi)如何搜索網(wǎng)頁關(guān)鍵詞
這里寫目錄標(biāo)題
- 一、持久化簡介
- 1.1 持久化
- 1.2 Redis持久化的兩種形式
- 二、RDB
- 2.1 RDB概念
- 2.2 save指令
- 手動(dòng)執(zhí)行一次保存
- 配置相關(guān)參數(shù)
- 2.3 bgsave指令
- 2.4 save配置自動(dòng)執(zhí)行
- 2.5 RDB三種啟動(dòng)方式對(duì)比
- 三、AOF
- 3.1 AOF概念
- 3.2 AOF執(zhí)行策略
- 3.3 AOF重寫
- 四、RDB和AOF區(qū)別
- 2.1 RDB與AOF對(duì)比(優(yōu)缺點(diǎn))
- 2.1 RDB與AOF應(yīng)用場景
一、持久化簡介
1.1 持久化
??利用存儲(chǔ)介質(zhì)將數(shù)據(jù)進(jìn)行保存,在特定的時(shí)間將保存的數(shù)據(jù)進(jìn)行恢復(fù)的工作機(jī)制稱為持久化 。
??持久化用于防止數(shù)據(jù)的意外丟失,確保數(shù)據(jù)安全性。
??把數(shù)據(jù)加載到內(nèi)存的過程叫做數(shù)據(jù)恢復(fù)。
??redis是一個(gè)內(nèi)存數(shù)據(jù)庫,一旦斷電或服務(wù)器進(jìn)程退出,內(nèi)存數(shù)據(jù)庫中的數(shù)據(jù)將全部丟失,所以需要redis持久化
1.2 Redis持久化的兩種形式
-
第一種:將當(dāng)前數(shù)據(jù)狀態(tài)進(jìn)行保存,快照形式,存儲(chǔ)數(shù)據(jù)結(jié)果,存儲(chǔ)格式簡單,關(guān)注點(diǎn)在數(shù)據(jù)。
-
第二種:將數(shù)據(jù)的操作過程進(jìn)行保存,日志形式,存儲(chǔ)操作過程,存儲(chǔ)格式復(fù)雜,關(guān)注點(diǎn)在數(shù)據(jù)的操作過程。
二、RDB
2.1 RDB概念
RDB,簡而言之,就是在不同的時(shí)間點(diǎn),將redis存儲(chǔ)的數(shù)據(jù)生成快照并存儲(chǔ)到磁盤等介質(zhì)上。
2.2 save指令
手動(dòng)執(zhí)行一次保存
save
配置相關(guān)參數(shù)
置本地?cái)?shù)據(jù)庫文件名,默認(rèn)值為 dump.rdb,通常設(shè)置為dump-端口號(hào).rdb
dbfilename filename
設(shè)置存儲(chǔ).rdb文件的路徑,通常設(shè)置成存儲(chǔ)空間較大的目錄中,注意目錄名稱必須要存在
dir path
設(shè)置存儲(chǔ)至本地?cái)?shù)據(jù)庫時(shí)是否壓縮數(shù)據(jù),默認(rèn)yes,設(shè)置為no,節(jié)省 CPU 運(yùn)行時(shí)間,但存儲(chǔ)文件變大
rdbcompression yes|no
設(shè)置讀寫文件過程是否進(jìn)行RDB格式校驗(yàn),默認(rèn)yes,設(shè)置為no,節(jié)約讀寫10%時(shí)間消耗,單存在數(shù)據(jù)損壞的風(fēng)險(xiǎn)
rdbchecksum yes|no
save指令工作原理
??現(xiàn)在有四個(gè)客戶端各自要執(zhí)行一個(gè)指令,把這些指令發(fā)送到redis服務(wù)器后,他們執(zhí)行有一個(gè)先后順序問題,redis是個(gè)單線程的工作模式,它會(huì)創(chuàng)建一個(gè)任務(wù)隊(duì)列,所有的命令都會(huì)進(jìn)到這個(gè)隊(duì)列里邊,在這兒排隊(duì)執(zhí)行,執(zhí)行完一個(gè)消失一個(gè),當(dāng)所有的命令都執(zhí)行完了,OK,結(jié)果達(dá)到了。
??但是如果現(xiàn)在我們執(zhí)行的時(shí)候save指令保存的數(shù)據(jù)量很大會(huì)是什么現(xiàn)象呢?
??他會(huì)非常耗時(shí),以至于影響到它在執(zhí)行的時(shí)候,后面的指令都要等,所以說這種模式是不友好的,這是save指令對(duì)應(yīng)的一個(gè)問題,當(dāng)cpu執(zhí)行的時(shí)候會(huì)阻塞redis服務(wù)器,直到他執(zhí)行完畢,所以說我們不建議大家在線上環(huán)境用save指令。
2.3 bgsave指令
save單線程執(zhí)行方式造成效率過低,bgsave指令,bg其實(shí)是background的意思,后臺(tái)執(zhí)行。
手動(dòng)啟動(dòng)后臺(tái)保存操作,但不是立即執(zhí)行
bgsave
bgsave指令相關(guān)配置
后臺(tái)存儲(chǔ)過程中如果出現(xiàn)錯(cuò)誤現(xiàn)象,是否停止保存操作,默認(rèn)yes
stop-writes-on-bgsave-error yes|no
其 他
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
bgsave指令工作原理
當(dāng)執(zhí)行bgsave的時(shí)候,客戶端發(fā)出bgsave指令給到redis服務(wù)器。注意,這個(gè)時(shí)候服務(wù)器馬上回一個(gè)結(jié)果告訴客戶端后臺(tái)已經(jīng)開始了,與此同時(shí)它會(huì)創(chuàng)建一個(gè)子進(jìn)程,使用Linux的fork函數(shù)創(chuàng)建一個(gè)子進(jìn)程,讓這個(gè)子進(jìn)程去執(zhí)行save相關(guān)的操作,此時(shí)我們可以想一下,我們主進(jìn)程一直在處理指令,而子進(jìn)程在執(zhí)行后臺(tái)的保存,它會(huì)不會(huì)干擾到主進(jìn)程的執(zhí)行嗎?
答案是不會(huì),所以說他才是主流方案。子進(jìn)程開始執(zhí)行之后,它就會(huì)創(chuàng)建啊RDB文件把它存起來,操作完以后他會(huì)把這個(gè)結(jié)果返回,也就是說bgsave的過程分成兩個(gè)過程,第一個(gè)是服務(wù)端拿到指令直接告訴客戶端開始執(zhí)行了;另外一個(gè)過程是一個(gè)子進(jìn)程在完成后臺(tái)的保存操作,操作完以后回一個(gè)消息。
2.4 save配置自動(dòng)執(zhí)行
設(shè)置自動(dòng)持久化的條件,滿足限定時(shí)間范圍內(nèi)key的變化數(shù)量達(dá)到指定數(shù)量即進(jìn)行持久化
save second changes
參數(shù)
second:監(jiān)控時(shí)間范圍
changes:監(jiān)控key的變化量
范例:
save 900 1
save 300 10
save 60 10000
其他相關(guān)配置:
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
stop-writes-on-bgsave-error yes|no
2.5 RDB三種啟動(dòng)方式對(duì)比
方式 | save指令 | bgsave指令 |
---|---|---|
讀寫 | 同步 | 異步 |
阻塞客戶端指令 | 是 | 否 |
額外內(nèi)存消耗 | 否 | 是 |
啟動(dòng)新進(jìn)程 | 否 | 是 |
RDB特殊啟動(dòng)形式
服務(wù)器運(yùn)行過程中重啟
debug reload
關(guān)閉服務(wù)器時(shí)指定保存數(shù)據(jù)
shutdown save
RDB優(yōu)點(diǎn):
- RDB是一個(gè)緊湊壓縮的二進(jìn)制文件,存儲(chǔ)效率較高
- RDB內(nèi)部存儲(chǔ)的是redis在某個(gè)時(shí)間點(diǎn)的數(shù)據(jù)快照,非常適合用于數(shù)據(jù)備份,全量復(fù)制等場景
- RDB恢復(fù)數(shù)據(jù)的速度要比AOF快很多
- 應(yīng)用:服務(wù)器中每X小時(shí)執(zhí)行bgsave備份,并將RDB文件拷貝到遠(yuǎn)程機(jī)器中,用于災(zāi)難恢復(fù)。
RDB缺點(diǎn)
- RDB方式無論是執(zhí)行指令還是利用配置,無法做到實(shí)時(shí)持久化,具有較大的可能性丟失數(shù)據(jù)
- bgsave指令每次運(yùn)行要執(zhí)行fork操作創(chuàng)建子進(jìn)程,要犧牲掉一些性能
- Redis的眾多版本中未進(jìn)行RDB文件格式的版本統(tǒng)一,有可能出現(xiàn)各版本服務(wù)之間數(shù)據(jù)格式無法兼容現(xiàn)象
三、AOF
3.1 AOF概念
AOF(append only file)持久化:以獨(dú)立日志的方式記錄每次寫命令,重啟時(shí)再重新執(zhí)行AOF文件中命令 達(dá)到恢復(fù)數(shù)據(jù)的目的。與RDB相比可以簡單理解為由記錄數(shù)據(jù)改為記錄數(shù)據(jù)產(chǎn)生的變化
AOF的主要作用是解決了數(shù)據(jù)持久化的實(shí)時(shí)性,目前已經(jīng)是Redis持久化的主流方式
啟動(dòng)AOF相關(guān)配置
開啟AOF持久化功能,默認(rèn)no,即不開啟狀態(tài)
appendonly yes|no
AOF持久化文件名,默認(rèn)文件名為appendonly.aof,建議配置為appendonly-端口號(hào).aof
appendfilename filename
AOF持久化文件保存路徑,與RDB持久化文件保持一致即可
dir
AOF寫數(shù)據(jù)策略,默認(rèn)為everysec
appendfsync always|everysec|no
3.2 AOF執(zhí)行策略
AOF寫數(shù)據(jù)三種策略(appendfsync)
-
always(每次):每次寫入操作均同步到AOF文件中數(shù)據(jù)零誤差,性能較低,不建議使用。
-
everysec(每秒):每秒將緩沖區(qū)中的指令同步到AOF文件中,在系統(tǒng)突然宕機(jī)的情況下丟失1秒內(nèi)的數(shù)據(jù) 數(shù)據(jù)準(zhǔn)確性較高,性能較高,建議使用,也是默認(rèn)配置
-
no(系統(tǒng)控制):由操作系統(tǒng)控制每次同步到AOF文件的周期,整體過程不可控
3.3 AOF重寫
- 什么叫AOF重寫?
隨著命令不斷寫入AOF,文件會(huì)越來越大,為了解決這個(gè)問題,Redis引入了AOF重寫機(jī)制壓縮文件體積。AOF文件重 寫是將Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新AOF文件的過程。簡單說就是將對(duì)同一個(gè)數(shù)據(jù)的若干個(gè)條命令執(zhí)行結(jié) 果轉(zhuǎn)化成最終結(jié)果數(shù)據(jù)對(duì)應(yīng)的指令進(jìn)行記錄。
AOF重寫作用
- 降低磁盤占用量,提高磁盤利用率
- 提高持久化效率,降低持久化寫時(shí)間,提高IO性能
- 降低數(shù)據(jù)恢復(fù)用時(shí),提高數(shù)據(jù)恢復(fù)效率
AOF重寫方式
- 手動(dòng)重寫
bgrewriteaof
自動(dòng)重寫
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
四、RDB和AOF區(qū)別
2.1 RDB與AOF對(duì)比(優(yōu)缺點(diǎn))
OF對(duì)比(優(yōu)缺點(diǎn))
持久化方式 | RDB | AOF |
---|---|---|
占用存儲(chǔ)空間 | 小(數(shù)據(jù)級(jí):壓縮) | 大(指令級(jí):重寫) |
存儲(chǔ)速度 | 慢 | 快 |
恢復(fù)速度 | 快 | 慢 |
數(shù)據(jù)安全性 | 會(huì)丟失數(shù)據(jù) | 依據(jù)策略決定 |
資源消耗 | 高/重量級(jí) | 低/輕量級(jí) |
啟動(dòng)優(yōu)先級(jí) | 低 | 高 |
2.1 RDB與AOF應(yīng)用場景
RDB與AOF的選擇之惑
- 對(duì)數(shù)據(jù)非常敏感,建議使用默認(rèn)的AOF持久化方案
AOF持久化策略使用everysecond,每秒鐘fsync一次。該策略redis仍可以保持很好的處理性能,當(dāng)出 現(xiàn)問題時(shí),最多丟失0-1秒內(nèi)的數(shù)據(jù)。
注意:由于AOF文件存儲(chǔ)體積較大,且恢復(fù)速度較慢
- 數(shù)據(jù)呈現(xiàn)階段有效性,建議使用RDB持久化方案
數(shù)據(jù)可以良好的做到階段內(nèi)無丟失(該階段是開發(fā)者或運(yùn)維人員手工維護(hù)的),且恢復(fù)速度較快,階段 點(diǎn)數(shù)據(jù)恢復(fù)通常采用RDB方案
注意:利用RDB實(shí)現(xiàn)緊湊的數(shù)據(jù)持久化會(huì)使Redis降的很低,慎重總結(jié):
綜合比對(duì)
- RDB與AOF的選擇實(shí)際上是在做一種權(quán)衡,每種都有利有弊
- 如不能承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失,對(duì)業(yè)務(wù)數(shù)據(jù)非常敏感,選用AOF
- 如能承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失,且追求大數(shù)據(jù)集的恢復(fù)速度,選用RDB
- 災(zāi)難恢復(fù)選用RDB
- 雙保險(xiǎn)策略,同時(shí)開啟 RDB和 AOF,重啟后,Redis優(yōu)先使用 AOF 來恢復(fù)數(shù)據(jù),降低丟失數(shù)據(jù)的量