一、持久化簡介

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ù)的量