Redis 提供了兩種持久化方式，一種是基于快照形式的 RDB，另一種是基于日志形式的 AOF，每種方式都有自己的優(yōu)缺點(diǎn)，本文將介紹 Redis 這兩種持久化方式，希望閱讀本文后你對(duì) Redis 的這兩種持久化方式有更加全面、清晰的認(rèn)識(shí)。

成都創(chuàng)新互聯(lián)是一家專業(yè)提供陽(yáng)信企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站制作、成都網(wǎng)站制作、H5建站、小程序制作等業(yè)務(wù)。10年已為陽(yáng)信眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。

RDB 快照方式持久化

先從 RDB 快照方式聊起，RDB 是 Redis 默認(rèn)開(kāi)啟的持久化方式，并不需要我們單獨(dú)開(kāi)啟，先來(lái)看看跟 RDB 相關(guān)的配置信息：

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#  will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#   save ""
# 自動(dòng)生成快照的觸發(fā)機(jī)制 中間的是時(shí)間，單位秒，后面的是變更數(shù)據(jù) 60 秒變更 10000 條數(shù)據(jù)則自動(dòng)生成快照
save 900 1
save 300 10
save 60 10000

# 生成快照失敗時(shí)，主線程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否采用壓縮算法存儲(chǔ)
rdbcompression yes

# 數(shù)據(jù)恢復(fù)時(shí)是否檢測(cè) RDB文件有效性
rdbchecksum yes

# The filename where to dump the DB
# RDB 快照生成的文件名稱
dbfilename dump.rdb

# 快照生成的路徑 AOF 也是存放在這個(gè)路徑下面
dir .

關(guān)于 RDB 相關(guān)配置信息不多，需要我們調(diào)整的就更少了，我們只需要根據(jù)自己的業(yè)務(wù)量修改生成快照的機(jī)制和文件存放路徑即可。

RDB 有兩種持久化方式：手動(dòng)觸發(fā)?和?自動(dòng)觸發(fā)，手動(dòng)觸發(fā)使用以下兩個(gè)命令：

• save：會(huì)阻塞當(dāng)前 Redis 服務(wù)器響應(yīng)其他命令，直到 RDB 快照生成完成為止，對(duì)于內(nèi)存 比較大的實(shí)例會(huì)造成長(zhǎng)時(shí)間阻塞，所以線上環(huán)境不建議使用

• bgsave：Redis 主進(jìn)程會(huì) fork 一個(gè)子進(jìn)程，RDB 快照生成有子進(jìn)程來(lái)負(fù)責(zé)，完成之后，子進(jìn)程自動(dòng)結(jié)束，bgsave 只會(huì)在 fork 子進(jìn)程的時(shí)候短暫的阻塞，這個(gè)過(guò)程是非常短的，所以推薦使用該命令來(lái)手動(dòng)觸發(fā)

除了執(zhí)行命令手動(dòng)觸發(fā)之外，Redis 內(nèi)部還存在自動(dòng)觸發(fā) RDB 的持久化機(jī)制，在以下幾種情況下 Redis 會(huì)自動(dòng)觸發(fā) RDB 持久化：

• 在配置中配置了 save 相關(guān)配置信息，如我們上面配置文件中的?save 60 10000?，也可以把它歸類為“save m n”格式的配置，表示 m 秒內(nèi)數(shù)據(jù)集存在 n 次修改時(shí)，會(huì)自動(dòng)觸發(fā) bgsave。

• 在主從情況下，如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，主節(jié)點(diǎn)自動(dòng)執(zhí)行 bgsave 生成 RDB 文件并發(fā)送給從節(jié)點(diǎn)

• 執(zhí)行 debug reload 命令重新加載 Redis 時(shí)，也會(huì)自動(dòng)觸發(fā) save 操作

• 默認(rèn)情況下執(zhí)行 shutdown 命令時(shí)，如果沒(méi)有開(kāi)啟 AOF 持久化功能則自動(dòng)執(zhí)行 bgsave

上面就是 RDB 持久化的方式，可以看出 save 命令使用的比較少，大多數(shù)情況下使用的都是 bgsave 命令，所以這個(gè) bgsave 命令還是有一些東西，那接下來(lái)我們就一起看看 bgsave 背后的原理，先從流程圖開(kāi)始入手：

bgsave 命令大概有以下幾個(gè)步驟：

• 1、執(zhí)行 bgsave 命令，Redis 主進(jìn)程判斷當(dāng)前是否存在正在執(zhí)行的 RDB/AOF 子進(jìn)程，如果存在， bgsave 命令直接返回不在往下執(zhí)行。
• 2、父進(jìn)程執(zhí)行 fork 操作創(chuàng)建子進(jìn)程，fork 操作過(guò)程中父進(jìn)程會(huì)阻塞，fork 完成后父進(jìn)程將不在阻塞可以接受其他命令。
• 3、子進(jìn)程創(chuàng)建新的 RDB 文件，基于父進(jìn)程當(dāng)前內(nèi)存數(shù)據(jù)生成臨時(shí)快照文件，完成后用新的 RDB 文件替換原有的 RDB 文件，并且給父進(jìn)程發(fā)送 RDB 快照生成完畢通知

上面就是 bgsave 命令背后的一些內(nèi)容，RDB 的內(nèi)容就差不多了，我們一起來(lái)總結(jié) RDB 持久化的優(yōu)缺點(diǎn)，RDB 方式的優(yōu)點(diǎn)：

• RDB 快照是某一時(shí)刻 Redis 節(jié)點(diǎn)內(nèi)存數(shù)據(jù)，非常適合做備份，上傳到遠(yuǎn)程服務(wù)器或者文件系統(tǒng)中，用于容災(zāi)備份
• 數(shù)據(jù)恢復(fù)時(shí) RDB 要遠(yuǎn)遠(yuǎn)快于 AOF

有優(yōu)點(diǎn)同樣存在缺點(diǎn)，RDB 的缺點(diǎn)有：

• RDB 持久化方式數(shù)據(jù)沒(méi)辦法做到實(shí)時(shí)持久化/秒級(jí)持久化。我們已經(jīng)知道了 bgsave 命令每次運(yùn)行都要執(zhí)行 fork 操作創(chuàng)建子進(jìn)程，屬于重量級(jí)操作，頻繁執(zhí)行成本過(guò)高。
• RDB 文件使用特定二進(jìn)制格式保存，Redis 版本演進(jìn)過(guò)程中有多個(gè)格式 的 RDB 版本，存在老版本 Redis 服務(wù)無(wú)法兼容新版 RDB 格式的問(wèn)題

如果我們對(duì)數(shù)據(jù)要求比較高，每一秒的數(shù)據(jù)都不能丟，RDB 持久化方式肯定是不能夠滿足要求的，那 Redis 有沒(méi)有辦法滿足呢，答案是有的，那就是接下來(lái)的 AOF 持久化方式

AOF 文件持久化方式

Redis 默認(rèn)并沒(méi)有開(kāi)啟 AOF 持久化方式，需要我們自行開(kāi)啟，在 redis.conf 配置文件中將?appendonly no?調(diào)整為?appendonly yes，這樣就開(kāi)啟了 AOF 持久化，與 RDB 不同的是 AOF 是以記錄操作命令的形式來(lái)持久化數(shù)據(jù)的，我們可以查看以下 AOF 的持久化文件?appendonly.aof

*2
$6
SELECT
$1
0
*3
$3
set
$6
mykey1
$6
你好
*3
$3
set
$4
key2
$5
hello
*1
$8

大概就是長(zhǎng)這樣的，具體的你可以查看你 Redis 服務(wù)器上的?appendonly.aof?配置文件，這也意味著我們可以在?appendonly.aof?文件中國(guó)修改值，等 Redis 重啟時(shí)將會(huì)加載修改之后的值?？此埔恍┖?jiǎn)單的操作命令，其實(shí)從命令到?appendonly.aof?這個(gè)過(guò)程中非常有學(xué)問(wèn)的，下面時(shí) AOF 持久化流程圖：

在 AOF 持久化過(guò)程中有兩個(gè)非常重要的操作：一個(gè)是將操作命令追加到 AOF_BUF 緩存區(qū)，另一個(gè)是 AOF_buf 緩存區(qū)數(shù)據(jù)同步到 AOF 文件，接下來(lái)我們?cè)敿?xì)聊一聊這兩個(gè)操作：

1、為什么要將命令寫入到 aof_buf 緩存區(qū)而不是直接寫入到 aof 文件？

我們知道 Redis 是單線程響應(yīng)，如果每次寫入 AOF 命令都直接追加到磁盤上的 AOF 文件中，這樣頻繁的 IO 開(kāi)銷，Redis 的性能就完成取決于你的機(jī)器硬件了，為了提升 Redis 的響應(yīng)效率就添加了一層 aof_buf 緩存層， 利用的是操作系統(tǒng)的 cache 技術(shù)，這樣就提升了 Redis 的性能，雖然這樣性能是解決了，但是同時(shí)也引入了一個(gè)問(wèn)題，aof_buf 緩存區(qū)數(shù)據(jù)如何同步到 AOF 文件呢？由誰(shuí)同步呢？這就是我們接下來(lái)要聊的一個(gè)操作：fsync 操作

2、aof_buf 緩存區(qū)數(shù)據(jù)如何同步到 aof 文件中？

aof_buf 緩存區(qū)數(shù)據(jù)寫入到 aof 文件是有 linux 系統(tǒng)去完成的，由于 Linux 系統(tǒng)調(diào)度機(jī)制周期比較長(zhǎng)，如果系統(tǒng)故障宕機(jī)了，意味著一個(gè)周期內(nèi)的數(shù)據(jù)將全部丟失，這不是我們想要的，所以 Linux 提供了一個(gè) fsync 命令，fsync 是針對(duì)單個(gè)文件操作（比如這里的 AOF 文件），做強(qiáng)制硬盤同步，fsync 將阻塞直到寫入硬盤完成后返回，保證了數(shù)據(jù)持久化，正是由于有這個(gè)命令，所以 redis 提供了配置項(xiàng)讓我們自行決定何時(shí)進(jìn)行磁盤同步，redis 在 redis.conf 中提供了appendfsync?配置項(xiàng)，有如下三個(gè)選項(xiàng)：

# appendfsync always
appendfsync everysec
# appendfsync no

• always：每次有寫入命令都進(jìn)行緩存區(qū)與磁盤數(shù)據(jù)同步，這樣保證不會(huì)有數(shù)據(jù)丟失，但是這樣會(huì)導(dǎo)致 redis 的吞吐量大大下降，下降到每秒只能支持幾百的 TPS ，這違背了 redis 的設(shè)計(jì)，所以不推薦使用這種方式
• everysec：這是 redis 默認(rèn)的同步機(jī)制，雖然每秒同步一次數(shù)據(jù)，看上去時(shí)間也很快的，但是它對(duì) redis 的吞吐量沒(méi)有任何影響，每秒同步一次的話意味著最壞的情況下我們只會(huì)丟失 1 秒的數(shù)據(jù)， 推薦使用這種同步機(jī)制，兼顧性能和數(shù)據(jù)安全
• no：不做任何處理，緩存區(qū)與 aof 文件同步交給系統(tǒng)去調(diào)度，操作系統(tǒng)同步調(diào)度的周期不固定，最長(zhǎng)會(huì)有 30 秒的間隔，這樣出故障了就會(huì)丟失比較多的數(shù)據(jù)。

這就是三種磁盤同步策略，但是你有沒(méi)有注意到一個(gè)問(wèn)題，AOF 文件都是追加的，隨著服務(wù)器的運(yùn)行 AOF 文件會(huì)越來(lái)越大，體積過(guò)大的 AOF 文件對(duì) redis 服務(wù)器甚至是主機(jī)都會(huì)有影響，而且在 Redis 重啟時(shí)加載過(guò)大的 AOF 文件需要過(guò)多的時(shí)間，這些都是不友好的，那 Redis 是如何解決這個(gè)問(wèn)題的呢？Redis 引入了重寫機(jī)制來(lái)解決 AOF 文件過(guò)大的問(wèn)題。

3、Redis 是如何進(jìn)行 AOF 文件重寫的？

Redis AOF 文件重寫是把 Redis 進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新 AOF 文件的過(guò)程，重寫之后的 AOF 文件會(huì)比舊的 AOF 文件占更小的體積，這是由以下幾個(gè)原因?qū)е碌模?/p>

• 進(jìn)程內(nèi)已經(jīng)超時(shí)的數(shù)據(jù)不再寫入文件
• 舊的 AOF 文件含有無(wú)效命令，如 del key1、hdel key2、srem keys、set a111、set a222等。重寫使用進(jìn)程內(nèi)數(shù)據(jù)直接生成，這樣新的AOF文件只保 留最終數(shù)據(jù)的寫入命令
• 多條寫命令可以合并為一個(gè)，如：lpush list a、lpush list b、lpush list c可以轉(zhuǎn)化為：lpush list a b c。為了防止單條命令過(guò)大造成客戶端緩沖區(qū)溢 出，對(duì)于 list、set、hash、zset 等類型操作，以 64 個(gè)元素為界拆分為多條。

重寫之后的 AOF 文件體積更小了，不但能夠節(jié)約磁盤空間，更重要的是在 Redis 數(shù)據(jù)恢復(fù)時(shí)，更小體積的 AOF 文件加載時(shí)間更短。AOF 文件重寫跟 RDB 持久化一樣分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)，手動(dòng)觸發(fā)直接調(diào)用?bgrewriteaof?命令就好了，我們后面會(huì)詳細(xì)聊一聊這個(gè)命令，自動(dòng)觸發(fā)就需要我們?cè)?redis.conf 中修改以下幾個(gè)配置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• auto-aof-rewrite-percentage：代表當(dāng)前 AOF文件空間 （aof_current_size）和上一次重寫后 AOF 文件空間（aof_base_size）的比值，默認(rèn)是 100%，也就是一樣大的時(shí)候
• auto-aof-rewrite-min-size：表示運(yùn)行 AOF 重寫時(shí) AOF 文件最小體積，默認(rèn)為 64MB，也就是說(shuō) AOF 文件最小為 64MB 才有可能觸發(fā)重寫

滿足了這兩個(gè)條件，Redis 就會(huì)自動(dòng)觸發(fā) AOF 文件重寫，AOF 文件重寫的細(xì)節(jié)跟 RDB 持久化生成快照有點(diǎn)類似，下面是 AOF 文件重寫流程圖：

AOF 文件重寫也是交給子進(jìn)程來(lái)完成，跟 RDB 生成快照很像，AOF 文件重寫在重寫期間建立了一個(gè) aof_rewrite_buf 緩存區(qū)來(lái)保存重寫期間主進(jìn)程響應(yīng)的命令，等新的 AOF 文件重寫完成后，將這部分文件同步到新的 AOF 文件中，最后用新的 AOF 文件替換掉舊的 AOF 文件。需要注意的是在重寫期間，舊的 AOF 文件依然會(huì)進(jìn)行磁盤同步，這樣做的目的是防止重寫失敗導(dǎo)致數(shù)據(jù)丟失，

Redis 持久化數(shù)據(jù)恢復(fù)

我們知道 Redis 是基于內(nèi)存的，所有的數(shù)據(jù)都存放在內(nèi)存中，由于機(jī)器宕機(jī)或者其他因素重啟了就會(huì)導(dǎo)致我們的數(shù)據(jù)全部丟失，這也就是要做持久化的原因，當(dāng)服務(wù)器重啟時(shí)，Redis 會(huì)從持久化文件中加載數(shù)據(jù)，這樣我們的數(shù)據(jù)就恢復(fù)到了重啟前的數(shù)據(jù)，在數(shù)據(jù)恢復(fù)這一塊Redis 是如何實(shí)現(xiàn)的？我們先來(lái)看看數(shù)據(jù)恢復(fù)的流程圖：

Redis 的數(shù)據(jù)恢復(fù)流程比較簡(jiǎn)單，優(yōu)先恢復(fù)的是 AOF 文件，如果 AOF 文件不存在時(shí)則嘗試加載 RDB 文件，為什么 RDB 的恢復(fù)速度比 AOF 文件快，但是還是會(huì)優(yōu)先加載 AOF 文件呢？我個(gè)人認(rèn)為是 AOF 文件數(shù)據(jù)更全面并且 AOF 兼容性比 RDB 強(qiáng)，需要注意的是當(dāng)存在 RDB/AOF 時(shí)，如果數(shù)據(jù)加載不成功，Redis 服務(wù)啟動(dòng)會(huì)失敗。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

當(dāng)前名稱：一文帶你深入了解Redis的持久化方式及其原理-創(chuàng)新互聯(lián)
文章鏈接：http://www.rwnh.cn/article12/ccgddc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、App設(shè)計(jì)、品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站改版、云服務(wù)器、營(yíng)銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)