Redis RDB技術(shù)底層原理詳解

每日一句

低頭是一種能力，它不是自卑，也不是怯弱，它是清醒中的嬗變。有時(shí)，稍微低一下頭，或者我們的人生路會(huì)更精彩。

前提概要

Redis是一個(gè)的鍵-值（K-V）對(duì)的內(nèi)存數(shù)據(jù)庫(kù)服務(wù)，通常包含了任意個(gè)非空數(shù)據(jù)庫(kù)。而每個(gè)非空的鍵值數(shù)據(jù)庫(kù)中又可以存放任意個(gè)K-V，基本的結(jié)構(gòu)如下圖所示：

• Redis的強(qiáng)勁性能很大程度上是由于其將所有數(shù)據(jù)都存儲(chǔ)在了內(nèi)存中，為了使Redis在重啟之后仍能保證數(shù)據(jù)不丟失，需要將數(shù)據(jù)從內(nèi)存中以某種形式同步到硬盤中，這一過程就是持久化。
• 我們知道redis中緩存的數(shù)據(jù)都存放在內(nèi)存中，一旦服務(wù)故障，會(huì)導(dǎo)致內(nèi)存中數(shù)據(jù)丟失，所以需要一種數(shù)據(jù)持久化的方案，將redis內(nèi)存中的數(shù)據(jù)，寫入磁盤，當(dāng)redis重啟后，能從磁盤中恢復(fù)數(shù)據(jù)。

Redis服務(wù)器的結(jié)構(gòu)

• 這里有一個(gè)問題，因?yàn)镽edis是一個(gè)內(nèi)存數(shù)據(jù)庫(kù)，如果它直接將數(shù)據(jù)存儲(chǔ)到內(nèi)存中，但是如果不考慮將存儲(chǔ)在內(nèi)存中的數(shù)據(jù)持久化到硬盤里面，一旦服務(wù)器進(jìn)程退出，那么數(shù)據(jù)庫(kù)中的數(shù)據(jù)也會(huì)消失。
• 數(shù)據(jù)庫(kù)的持久化機(jī)制主要有兩種，一種是RDB機(jī)制，另外一種是AOF機(jī)制，AOF機(jī)制已經(jīng)在前面的文章中介紹過了，
• 如果有興趣可以去看看，而本文主要講述RDB機(jī)制。

RDB持久化方式

RDB持久化是指在指定的時(shí)間間隔內(nèi)將redis內(nèi)存中的數(shù)據(jù)集快照寫入磁盤，實(shí)現(xiàn)原理是redis服務(wù)在指定的時(shí)間間隔內(nèi)先fork一個(gè)子進(jìn)程，由子進(jìn)程將數(shù)據(jù)集寫入臨時(shí)文件，寫入成功后，再替換之前的文件，用二進(jìn)制壓縮存儲(chǔ)，生成dump.rdb文件存放在磁盤中。

RDB機(jī)制

• Redis提供了RDB持久化能力，這個(gè)功能可以將Redis在內(nèi)存中的數(shù)據(jù)庫(kù)狀態(tài)保持在磁盤里面，避免數(shù)據(jù)意外丟失。
• RDB持久化機(jī)制可以手動(dòng)執(zhí)行，也可以根據(jù)服務(wù)器配置選定定期執(zhí)行操作，該功能可以將某一個(gè)時(shí)間點(diǎn)的數(shù)據(jù)快照進(jìn)行保存到一個(gè)RDB文件中。

RDB優(yōu)勢(shì)

• 一旦采用該方式，那么你的整個(gè)Redis數(shù)據(jù)庫(kù)將只包含一個(gè)文件，這對(duì)于文件備份而言是非常完美的。比如，你可能打算每個(gè)小時(shí)歸檔一次最近24小時(shí)的數(shù)據(jù)，同時(shí)還要每天歸檔一次最近30天的數(shù)據(jù)。通過這樣的備份策略，一旦系統(tǒng)出現(xiàn)災(zāi)難性故障，我們可以非常容易的進(jìn)行恢復(fù)。
• 對(duì)于災(zāi)難恢復(fù)而言，RDB是非常不錯(cuò)的選擇。因?yàn)槲覀兛梢苑浅］p松的將一個(gè)單獨(dú)的文件壓縮后再轉(zhuǎn)移到其它存儲(chǔ)介質(zhì)上。
• 性能最大化。對(duì)于Redis的服務(wù)進(jìn)程而言，在開始持久化時(shí)，它唯一需要做的只是fork出子進(jìn)程，之后再由子進(jìn)程完成這些持久化的工作，這樣就可以極大的避免服務(wù)進(jìn)程執(zhí)行IO操作了。
• 相比于AOF機(jī)制，如果數(shù)據(jù)集很大，RDB的啟動(dòng)效率會(huì)更高。

RDB劣勢(shì)

如果你想保證數(shù)據(jù)的高可用性，即最大限度的避免數(shù)據(jù)丟失，那么RDB將不是一個(gè)很好的選擇。因?yàn)橄到y(tǒng)一旦在定時(shí)持久化之前出現(xiàn)宕機(jī)現(xiàn)象，此前沒有來得及寫入磁盤的數(shù)據(jù)都將丟失。

由于RDB是通過fork子進(jìn)程來協(xié)助完成數(shù)據(jù)持久化工作的，因此，如果當(dāng)數(shù)據(jù)集較大時(shí)，可能會(huì)導(dǎo)致整個(gè)服務(wù)器停止服務(wù)幾百毫秒，甚至是1秒鐘。

RDB配置規(guī)則

在redis的6379.conf配置文件中：

備份配置參數(shù)

save seconds> changes>

save 指定時(shí)間間隔> 執(zhí)行指定次數(shù)更新操作>，滿足條件就將內(nèi)存中的數(shù)據(jù)同步到硬盤中。官方出廠配置默認(rèn)是 900秒內(nèi)有1個(gè)更改，300秒內(nèi)有10個(gè)更改以及60秒內(nèi)有10000個(gè)更改，則將內(nèi)存中的數(shù)據(jù)快照寫入磁盤。

save 900 1      #在900秒（15分鐘）之后，如果至少有一個(gè)key發(fā)生變化，則dump內(nèi)存快照
save 300 10     #在300秒（15分鐘）之后，如果至少有10個(gè)key發(fā)生變化，則dump內(nèi)存快照
save 60 10000   #在60秒（1分鐘）之后，如果至少有10000個(gè)key發(fā)生變化，則dump內(nèi)存快照

文件配置參數(shù)

默認(rèn)的rdb文件路徑是當(dāng)前目錄,文件名是dump.rdb,可以在配置文件中修改路徑和文件名,分別是dir和dbfilename.

# 存放快照的目錄
dir ./ # rdb文件存儲(chǔ)路徑
dbfilename dump.rdb # rdb文件名

壓縮配置參數(shù)

在進(jìn)行鏡像備份時(shí),是否進(jìn)行壓縮。

rdbcompression yes  #Redis默認(rèn)是開啟壓縮的。
# yes：壓縮，但是需要一些cpu的消耗。
# no：不壓縮，需要更多的磁盤空間。

如果沒有觸發(fā)自動(dòng)快照,需要對(duì)Redis執(zhí)行手動(dòng)快照操作,save和bgsave命令來手動(dòng)快照,兩個(gè)命令是：

• SAVE：由主進(jìn)程進(jìn)行快照，會(huì)阻塞其他請(qǐng)求。
• BGSAVE：通過fork子進(jìn)程進(jìn)行快照，不會(huì)阻塞其他請(qǐng)求。

注意:由于Redis使用fork來復(fù)制一份當(dāng)前進(jìn)程,那么子進(jìn)程就會(huì)占有和主進(jìn)程一樣的內(nèi)存資源,比如說主進(jìn)程8G內(nèi)存,那么在備份的時(shí)候,必須保證有16G的內(nèi)存,要不然會(huì)啟用虛擬內(nèi)存,性能非常的差。

快照的過程如下：

• Redis使用fork函數(shù)復(fù)制一份當(dāng)前進(jìn)程（父進(jìn)程）的副本（子進(jìn)程）；
• 父進(jìn)程繼續(xù)接收并處理客戶端發(fā)來的命令，而子進(jìn)程開始將內(nèi)存中的數(shù)據(jù)寫入硬盤中的臨時(shí)文件；
• 當(dāng)子進(jìn)程寫入完所有數(shù)據(jù)后會(huì)用該臨時(shí)文件替換舊的RDB文件，至此一次快照操作完成。（注意：會(huì)存在寫一部命令壓縮緩存區(qū)，記錄寫入rdb文件時(shí)候的操作）

在執(zhí)行fork的時(shí)候操作系統(tǒng)會(huì)使用寫時(shí)復(fù)制（copy-on-write）策略，即fork函數(shù)發(fā)生的一刻父子進(jìn)程共享同一內(nèi)存數(shù)據(jù)，當(dāng)父進(jìn)程要更改其中某片數(shù)據(jù)時(shí)（如執(zhí)行一個(gè)寫命令），操作系統(tǒng)會(huì)將該片數(shù)據(jù)復(fù)制一份以保證子進(jìn)程的數(shù)據(jù)不受影響，所以新的RDB文件存儲(chǔ)的是執(zhí)行fork時(shí)那一刻的內(nèi)存快照數(shù)據(jù)。

通過上述過程可以發(fā)現(xiàn)Redis在進(jìn)行快照的過程中不會(huì)修改RDB文件，只有快照結(jié)束后才會(huì)將舊的文件替換成新的，也就是說任何時(shí)候RDB文件都是完整的。這使得可以通過定時(shí)備份RDB文件來實(shí)現(xiàn)Redis數(shù)據(jù)庫(kù)備份。

快照的過程壓縮分析：

RDB文件是經(jīng)過壓縮（上文介紹了：可以配置rdbcompression參數(shù)以禁用壓縮節(jié)省CPU占用）的二進(jìn)制格式，所以占用的空間會(huì)小于內(nèi)存中的數(shù)據(jù)大小，更加利于傳輸。

快照的讀取加載過程：

• Redis啟動(dòng)后會(huì)讀取RDB快照文件，將數(shù)據(jù)從硬盤載入到內(nèi)存。根據(jù)數(shù)據(jù)量大小與結(jié)構(gòu)和服務(wù)器性能不同，這個(gè)時(shí)間也不同。通常將一個(gè)記錄一千萬個(gè)字符串類型鍵、大小為1GB的快照文件載入到內(nèi)存中需要花費(fèi)20～30秒鐘。
• 通過RDB方式實(shí)現(xiàn)持久化，一旦Redis異常退出，就會(huì)丟失最后一次快照以后更改的所有數(shù)據(jù)。這就需要開發(fā)者根據(jù)具體的應(yīng)用場(chǎng)合，通過組合設(shè)置自動(dòng)快照條件的方式來將可能發(fā)生的數(shù)據(jù)損失控制在能夠接受的范圍。如果數(shù)據(jù)很重要以至于無法承受任何損失，則可以考慮使用AOF方式進(jìn)行持久化。

RDB 的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

1. 適合大規(guī)模的數(shù)據(jù)恢復(fù)。
2. 如果業(yè)務(wù)對(duì)數(shù)據(jù)完整性和一致性要求不高，RDB是很好的選擇。

缺點(diǎn)：

• 數(shù)據(jù)的完整性和一致性不高，因?yàn)镽DB可能在最后一次備份時(shí)宕機(jī)了。
• 備份時(shí)占用內(nèi)存，因?yàn)镽edis 在備份時(shí)會(huì)獨(dú)立創(chuàng)建一個(gè)子進(jìn)程，將數(shù)據(jù)寫入到一個(gè)臨時(shí)文件（此時(shí)內(nèi)存中的數(shù)據(jù)是原來的兩倍），最后再將臨時(shí)文件替換之前的備份文件。
• 由于RDB是通過fork子進(jìn)程來協(xié)助完成數(shù)據(jù)持久化工作的，因此，如果當(dāng)數(shù)據(jù)集較大時(shí)，可能會(huì)導(dǎo)致整個(gè)服務(wù)器停止服務(wù)幾百毫秒，甚至是1秒鐘。(回寫和覆蓋的時(shí)候用的是主進(jìn)程)。

RDB與AOF二者選擇的標(biāo)準(zhǔn)（雖然還沒有講AOF，提前普及）

• 如果系統(tǒng)是愿意犧牲一些性能，換取更高的緩存一致性（aof）
• 或者是愿意寫操作頻繁的時(shí)候，不啟用備份來換取更高的性能，待手動(dòng)運(yùn)行save的時(shí)候，再做備份（rdb）。

Redis允許同時(shí)開啟AOF和RDB，既保證了數(shù)據(jù)安全又使得進(jìn)行備份等操作十分容易。此時(shí)重新啟動(dòng)Redis后Redis會(huì)使用AOF文件來恢復(fù)數(shù)據(jù)，因?yàn)锳OF方式的持久化可能丟失的數(shù)據(jù)更少。

總結(jié)

• Redis 默認(rèn)開啟RDB持久化方式，在指定的時(shí)間間隔內(nèi)，執(zhí)行指定次數(shù)的寫操作，則將內(nèi)存中的數(shù)據(jù)寫入到磁盤中。
• RDB 持久化適合大規(guī)模的數(shù)據(jù)恢復(fù)但它的數(shù)據(jù)一致性和完整性較差。
• Redis 需要手動(dòng)開啟AOF持久化方式，默認(rèn)是每秒將寫操作日志追加到AOF文件中。

所以Redis的持久化和數(shù)據(jù)的恢復(fù)要選擇在夜深人靜的時(shí)候執(zhí)行是比較合理的。

到此這篇關(guān)于Redis RDB技術(shù)底層原理詳解的文章就介紹到這了,更多相關(guān)Redis RDB底層原理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！