[[349785]]

本文轉(zhuǎn)載自微信公眾號(hào)「IT界農(nóng)民工」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系IT界農(nóng)民工公眾號(hào)。

作為內(nèi)存數(shù)據(jù)庫(kù)，Redis 在數(shù)據(jù)存儲(chǔ)與讀取上的速度是毫不遜色的，這點(diǎn)毋庸置疑。但是對(duì)于內(nèi)存來(lái)說(shuō)，斷電或遇到故障后數(shù)據(jù)就會(huì)丟失，這卻是一個(gè)無(wú)法回避的問(wèn)題。令人欣慰的是，基于這樣的缺點(diǎn)，Redis 也提供了不同的持久化方案。

各位看官請(qǐng)隨小萊接著往下看：

- 思維導(dǎo)圖 -

RDB持久化

對(duì)于 Redis 持久化來(lái)說(shuō)，其實(shí)就是將存儲(chǔ)在內(nèi)存中的數(shù)據(jù)寫(xiě)入到磁盤(pán)里，只不過(guò)寫(xiě)入的方式是有一定策略的。

那么我們先來(lái)看下第一種持久化，首先出場(chǎng)的是 RDB。

1、什么是RDB持久化

英文名稱(chēng)是 Redis DataBase，它還有一個(gè)常用的名字：快照持久化。所謂快照，在這里指的是某一時(shí)刻的內(nèi)存數(shù)據(jù)，而持久化則是將這一時(shí)刻的數(shù)據(jù)以二進(jìn)制形式寫(xiě)入到磁盤(pán)里。

2、手動(dòng)觸發(fā)機(jī)制

(1)save 命令

你可能會(huì)問(wèn)了，那我通過(guò)什么樣的方式來(lái)實(shí)現(xiàn)持久化呢?不知道你有沒(méi)有用過(guò) save 這個(gè)命令，在 Redis 里擔(dān)任的角色是用來(lái)手動(dòng)觸發(fā)持久化的。也就是說(shuō)在 Redis 客戶(hù)端操作 save 命令就可以將內(nèi)存數(shù)據(jù)寫(xiě)入到磁盤(pán)里。

不過(guò)你可千萬(wàn)不要好奇，生產(chǎn)環(huán)境要是這么玩兒的話，數(shù)據(jù)量少還行，數(shù)量大的話那估計(jì)八成得涼涼。為什么這么說(shuō)呢?你稍微了解下它的運(yùn)行原理就知道了。

前面的文章中，我們提到了 Redis 處理命令的方式是以單線程形式來(lái)進(jìn)行的?？蛻?hù)端的請(qǐng)求都會(huì)放入一個(gè)隊(duì)列里。當(dāng)執(zhí)行 save 命令時(shí)，如果執(zhí)行時(shí)間很長(zhǎng)的話，后面的請(qǐng)求就會(huì)被阻塞，客戶(hù)端發(fā)送的所有命令都會(huì)被拒絕。

這種方式生產(chǎn)場(chǎng)景要慎用!

(2)bgsave 命令

還有一個(gè) bgsave 命令。與 save 不同的是，執(zhí)行過(guò)程中它并不會(huì)阻塞客戶(hù)端的請(qǐng)求。而是將持久化工作交給子進(jìn)程來(lái)執(zhí)行，主進(jìn)程仍負(fù)責(zé)客戶(hù)端請(qǐng)求的處理工作。

3、自動(dòng)觸發(fā)機(jī)制

RDB 持久化既可以通過(guò)手動(dòng)觸發(fā)，也可以通過(guò)服務(wù)器配置項(xiàng)來(lái)定期執(zhí)行。

自動(dòng)觸發(fā)通常是 Redis 中配置文件來(lái)執(zhí)行的。有這么個(gè)配置你需要了解下：

save m n

其中 m 代表秒數(shù)，n 代表次數(shù)，放在一起表示的是 m 秒內(nèi)發(fā)生 n 次變化時(shí)，會(huì)觸發(fā) bgsave。

了解了自動(dòng)化配置，我們?cè)賮?lái)看下 Redis 配置文件 redis.conf 中的三個(gè)默認(rèn)配置項(xiàng)：

save 900 1 表示的是時(shí)間900秒內(nèi)，如果 Redis 中數(shù)據(jù)至少發(fā)生一次變化，就會(huì)執(zhí)行 bgsave。后邊兩個(gè)就不用介紹了，一樣的原理。

看到這三個(gè)配置項(xiàng)，不知道你會(huì)不會(huì)有疑問(wèn)，這三個(gè)到底該執(zhí)行哪一個(gè)?答案是設(shè)置多個(gè) save m n 命令時(shí)，滿足任何一個(gè)條件都會(huì)觸發(fā)持久化。

4、RDB 文件恢復(fù)

前面我們提到過(guò)了，持久化的目的就是為了解決內(nèi)存異常導(dǎo)致的數(shù)據(jù)丟失問(wèn)題。那么倘若如果真遇到了這樣的情況，RDB 文件如何來(lái)實(shí)現(xiàn)數(shù)據(jù)恢復(fù)呢?

開(kāi)啟自動(dòng)持久化后，數(shù)據(jù)會(huì)存儲(chǔ)到名為 dump.rdb 的文件中。當(dāng) Redis 服務(wù)器重啟時(shí)，檢測(cè)到 dump.rdb 文件后，會(huì)自動(dòng)加載進(jìn)行數(shù)據(jù)恢復(fù)。

AOF持久化

介紹完了 RDB 后，我們?cè)賮?lái)看一種叫作 AOF 的持久化方式。

1、什么是AOF持久化

英文名稱(chēng)是 Append Only File。同樣地，它也有一個(gè)常用的名字：文件追加持久化。與RDB 不同的是，它是通過(guò)保存所執(zhí)行的寫(xiě)命令來(lái)實(shí)現(xiàn)的，并且保存的數(shù)據(jù)格式是客戶(hù)端發(fā)送的命令。

2、AOF 實(shí)現(xiàn)方式

想要使用 AOF 持久化方式，需要啟用配置文件中的 appendonly 參數(shù)。默認(rèn)情況下，Redis 是不開(kāi)啟的。

開(kāi)啟 AOF 持久化后每執(zhí)行一條修改數(shù)據(jù)的命令，Redis 就會(huì)將該命令寫(xiě)入 aof_buf 緩沖區(qū)。后續(xù)寫(xiě)入 AOF 文件中的操作是由下面的配置來(lái)控制的：

這三個(gè)配置項(xiàng)分別表示

appendfsync always：每次寫(xiě)入都進(jìn)行刷盤(pán)操作，對(duì)性能影響最大，占用磁盤(pán) IO 較高，數(shù)據(jù)安全性最高。

appendfsync everysec：1秒刷一次盤(pán)，對(duì)性能影響相對(duì)較小。

appendfsync no：按照操作系統(tǒng)的機(jī)制進(jìn)行刷盤(pán)，對(duì)性能影響最小，數(shù)據(jù)安全性低。

3、AOF 重寫(xiě)機(jī)制

隨著命令的不斷寫(xiě)入，AOF 文件會(huì)變得越來(lái)越大，這時(shí)候該如何是好呢?別急，Redis 中提供了瘦身功能，也就是重寫(xiě)機(jī)制。

Redis 配置文件中有兩個(gè)對(duì)應(yīng)的參數(shù)是來(lái)決定重寫(xiě)機(jī)制的觸發(fā)時(shí)機(jī)的。

auto-aof-rewrite-percentage：AOF 文件距離上次文件增長(zhǎng)超過(guò)多少百分比

auto-aof-rewrite-min-size：AOF 文件體積最小多大以上觸發(fā)

滿足所設(shè)置的條件時(shí)，會(huì)自動(dòng)觸發(fā) AOF 重寫(xiě)，此時(shí) Redis 會(huì)掃描整個(gè)實(shí)例的數(shù)據(jù)，重新生成一個(gè) AOF 文件來(lái)達(dá)到瘦身的效果。

4、AOF 文件恢復(fù)

同樣地，我們也需要對(duì) AOF 文件進(jìn)行恢復(fù)。和 RBD 不同的是，Redis 中是通過(guò)創(chuàng)建一個(gè)不帶網(wǎng)絡(luò)連接的偽客戶(hù)端來(lái)進(jìn)行實(shí)現(xiàn)的。為什么要?jiǎng)?chuàng)建偽客戶(hù)端呢?你想想 AOF 文件中的數(shù)據(jù)格式，都是由命令組成的。通過(guò)客戶(hù)端直接執(zhí)行每條命令就可以將數(shù)據(jù)進(jìn)行恢復(fù)。

在這里需要注意的是，如果服務(wù)器開(kāi)啟了 AOF 持久化功能，會(huì)優(yōu)先使用 AOF 文件來(lái)進(jìn)行恢復(fù)。只有在 AOF 關(guān)閉狀態(tài)下，服務(wù)器才會(huì)使用 RDB 文件來(lái)進(jìn)行還原。

兩種持久化的優(yōu)/缺點(diǎn)

到這里，對(duì)兩種持久化也有了一定的認(rèn)識(shí)，那么我們來(lái)看看它們分別有什么優(yōu)點(diǎn)和缺點(diǎn)：

1、RDB 優(yōu)點(diǎn)與缺點(diǎn)

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

文件體積?。篟DB 的文件內(nèi)容是二進(jìn)制格式，因此體積比實(shí)例內(nèi)存小。

恢復(fù)速度快：當(dāng) Redis 實(shí)例恢復(fù)時(shí)，加載 RDB 文件速度很快，能在很短時(shí)間內(nèi)迅速恢復(fù)數(shù)據(jù)。

(2)缺點(diǎn)

數(shù)據(jù)缺失：RDB 保存的是某一時(shí)刻的數(shù)據(jù)，當(dāng) Redis 實(shí)例某一時(shí)刻異常時(shí)，會(huì)導(dǎo)致數(shù)據(jù)丟失。

消耗資源：RDB 文件的生成會(huì)消耗大量的 CPU 和內(nèi)存資源，有一定代價(jià)。

2、AOF 優(yōu)點(diǎn)與缺點(diǎn)

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

數(shù)據(jù)更完整：AOF 中是及時(shí)寫(xiě)入的方式，數(shù)據(jù)保存更完整?；謴?fù)時(shí)降低數(shù)據(jù)的損失率

易讀性強(qiáng)：AOF 中保存的數(shù)據(jù)格式是客戶(hù)端的寫(xiě)入命令，可讀性性強(qiáng)。

(2)缺點(diǎn)

文件體積大：AOF 中存儲(chǔ)客戶(hù)端所有的寫(xiě)命令，未經(jīng)壓縮，隨著命令的寫(xiě)入，文件會(huì)越來(lái)越大。

增加磁盤(pán)IO：AOF 文件刷盤(pán)如果采用每秒刷一次的方式會(huì)導(dǎo)致磁盤(pán)IO升高，影響性能。

混合持久化

既然 RDB 與 AOF 持久化都存在各自的缺點(diǎn)，那么有沒(méi)有一種更好的持久化方式?

接下來(lái)要介紹的是混合持久化。其實(shí)就是 RDB 與 AOF 的混合模式，這是 Redis4 之后新增的。

1、持久化方式

混合持久化是通過(guò) aof-use-rdb-preamble 參數(shù)來(lái)開(kāi)啟的。它的操作方式是這樣的，在寫(xiě)入的時(shí)候先把數(shù)據(jù)以 RDB 的形式寫(xiě)入文件的開(kāi)頭，再將后續(xù)的寫(xiě)命令以 AOF 的格式追加到文件中。這樣既能保證數(shù)據(jù)恢復(fù)時(shí)的速度，同時(shí)又能減少數(shù)據(jù)丟失的風(fēng)險(xiǎn)。

2、文件恢復(fù)

那么混合持久化中是如何來(lái)進(jìn)行數(shù)據(jù)恢復(fù)的呢?在 Redis 重啟時(shí)，先加載 RDB 的內(nèi)容，然后再重放增量 AOF 格式命令。這樣就避免了 AOF 持久化時(shí)的全量加載，從而使加載速率得到大幅提升。

總結(jié)

RDB持久化

• 將某一時(shí)刻的數(shù)據(jù)以二進(jìn)制形式寫(xiě)入到磁盤(pán)里，服務(wù)重啟時(shí)檢測(cè)到對(duì)應(yīng)文件自動(dòng)加載進(jìn)行數(shù)據(jù)恢復(fù)。
• 有手動(dòng)觸發(fā)和自動(dòng)觸發(fā)兩種機(jī)制。

AOF持久化

• 以文件追加的方式寫(xiě)入客戶(hù)端執(zhí)行的寫(xiě)命令。
• 數(shù)據(jù)恢復(fù)時(shí)，通過(guò)創(chuàng)建偽客戶(hù)端的方式執(zhí)行命令，直到恢復(fù)完成。

混合持久化

• 在寫(xiě)入的時(shí)候先把數(shù)據(jù)以 RDB 的形式寫(xiě)入文件的開(kāi)頭，再將后續(xù)的寫(xiě)命令以 AOF 的格式追加到文件中。