redis持久化的運(yùn)行機(jī)制和優(yōu)缺點(diǎn)是什么，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

創(chuàng)新互聯(lián)從2013年成立，先為五華等服務(wù)建站，五華等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為五華企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

前言

大家都知道Redis一個(gè)內(nèi)存數(shù)據(jù)庫(kù),它支持2種持久化方式：RDB(Snapshot 內(nèi)存快照) ，AOF(append only file)。持久化功能將內(nèi)存中的數(shù)據(jù)同步到磁盤(pán)來(lái)避免Redis發(fā)生異常導(dǎo)致數(shù)據(jù)丟失的情況。當(dāng)Redis實(shí)例重啟時(shí)，即可利用之前持久化的文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。

接下來(lái)，小編介紹兩種持久化的運(yùn)行機(jī)制和優(yōu)缺點(diǎn)。

一 RDB

RDB是默認(rèn)的持久化方式，按照一定的策略周期性的將內(nèi)存中的數(shù)據(jù)生成快照保存到磁盤(pán)。

每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫(xiě)入到磁盤(pán)一次，并不 是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫(xiě)操作比較多，必然會(huì)引起大量的磁盤(pán)io操作，可能會(huì)嚴(yán)重影響性能。

1.1 快照持久化過(guò)程

1.2 觸發(fā)機(jī)制

1. save 命令

當(dāng)客戶端向Redis server發(fā)送save命令請(qǐng)求進(jìn)行持久化時(shí)，由于Redis是用一個(gè)主線程來(lái)處理所有,save命令會(huì)阻塞Redis server處理其他客戶端的請(qǐng)求，直到數(shù)據(jù)同步完成。

2. bgsave命令

與save命令不同，bgsave是異步執(zhí)行的，當(dāng)執(zhí)行bgsave命令之后，Redis主進(jìn)程會(huì)fork 一個(gè)子進(jìn)程將數(shù)據(jù)保存到rdb文件中，同步完數(shù)據(jù)之后，對(duì)原有文件進(jìn)行替換，然后通知主進(jìn)程表示同步完成。

3. 自動(dòng)觸發(fā)

除了手動(dòng)觸發(fā)RDB持久化，Redis內(nèi)部還存在自動(dòng)觸發(fā)機(jī)制，

在配置中集中配置 save m n 的方式，表示 m秒內(nèi)數(shù)據(jù)集存在n次修改時(shí)，系統(tǒng)自動(dòng)觸發(fā)bgsave 操作。 

# 900s內(nèi)至少達(dá)到一條寫(xiě)命令      save 900 1      # 300s內(nèi)至少達(dá)至10條寫(xiě)命令      save 300 10      # 60s內(nèi)至少達(dá)到10000條寫(xiě)命令      save 60 10000

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

默認(rèn)情況下執(zhí)行 shutdown 命令時(shí)，如果沒(méi)有開(kāi)啟AOF持久化功能，系統(tǒng)會(huì)自動(dòng)執(zhí)行bgsave命令。執(zhí)行debug reload 命令重新加載Redis時(shí)，也會(huì)自動(dòng)觸發(fā)save操作。

1.3 相關(guān)參數(shù) 

# 持久化 rdb文件遇到問(wèn)題時(shí)，主進(jìn)程是否接受寫(xiě)入，yes 表示停止寫(xiě)入，如果是no 表示redis繼續(xù)提供服務(wù)。      stop-writes-on-bgsave-error yes      # 在進(jìn)行快照鏡像時(shí),是否進(jìn)行壓縮。yes:壓縮，但是需要一些cpu的消耗。no:不壓縮，需要更多的磁盤(pán)空間。      rdbcompression yes      # 一個(gè)CRC64的校驗(yàn)就被放在了文件末尾，當(dāng)存儲(chǔ)或者加載rbd文件的時(shí)候會(huì)有一個(gè)10%左右的性能下降，為了達(dá)到性能的最大化，你可以關(guān)掉這個(gè)配置項(xiàng)。      rdbchecksum yes      # 快照的文件名      dbfilename dump.rdb      # 存放快照的目錄      dir /var/lib/redis

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

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

RDB文件小，非常適合定時(shí)備份，用于災(zāi)難恢復(fù)。

因?yàn)镽DB文件中直接存儲(chǔ)的是內(nèi)存數(shù)據(jù)，而AOF文件中存儲(chǔ)的是一條條命令，需要應(yīng)用命令。Redis加載RDB文件的速度比AOF快很多。

缺點(diǎn)

RDB持久化方式不能做到實(shí)時(shí)/秒級(jí)持久化。實(shí)時(shí)持久化要全量刷內(nèi)存到磁盤(pán)，成本太高。每秒fork子進(jìn)程也會(huì)阻塞主進(jìn)程，影響性能。

RDB文件是二進(jìn)制文件，隨著Redis不斷迭代有多個(gè)rdb文件的版本，不支持跨版本兼容。老的Redis無(wú)法識(shí)別新的RDB文件格式。

二 AOF

AOF(Append-only file)針對(duì)RDB的缺點(diǎn)做了優(yōu)化，在使用AOF持久化方式時(shí)，Redis會(huì)將每一個(gè)收到的寫(xiě)操作命令都通過(guò)Write函數(shù)追加到文件最后，類似于MySQL的binlog。當(dāng)Redis重啟時(shí)會(huì)通過(guò)重新執(zhí)行文件中保存的寫(xiě)命令來(lái)在內(nèi)存中重建整個(gè)數(shù)據(jù)庫(kù)的內(nèi)容。

2.1 AOF持久化過(guò)程

1. 客戶端發(fā)出 bgrewriteaof命令。

2. redis主進(jìn)程fork子進(jìn)程。

3. 父進(jìn)程繼續(xù)處理client請(qǐng)求，除了把寫(xiě)命令寫(xiě)入到原來(lái)的aof文件中。同時(shí)把收到的寫(xiě)命令緩存到 AOF重寫(xiě)緩沖區(qū)。這樣就能保證如果子進(jìn)程重寫(xiě)失敗的話并不會(huì)出問(wèn)題。

4. 子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫(xiě)入到新AOF文件中。

5. 當(dāng)子進(jìn)程把內(nèi)存快照寫(xiě)入臨時(shí)文件中后，子進(jìn)程發(fā)信號(hào)通知父進(jìn)程。然后父進(jìn)程把緩存的寫(xiě)命令也寫(xiě)入到臨時(shí)文件。

6. 現(xiàn)在父進(jìn)程可以使用臨時(shí)文件替換老的aof文件，并重命名，后面收到的寫(xiě)命令也開(kāi)始往新的aof文件中追加。

2.2 相關(guān)參數(shù) 

# 是否開(kāi)啟AOF，默認(rèn)關(guān)閉      appendonly yes      # 指定 AOF 文件名      appendfilename appendonly.aof      # Redis支持三種刷寫(xiě)模式：      # appendfsync always #每次收到寫(xiě)命令就立即強(qiáng)制寫(xiě)入磁盤(pán)，類似MySQL的sync_binlog=1,是最安全的。但該模式下速度也是最慢的，一般不推薦使用。      appendfsync everysec #每秒鐘強(qiáng)制寫(xiě)入磁盤(pán)一次，在性能和持久化方面做平衡，推薦該方式。      # appendfsync no     #完全依賴OS的寫(xiě)入，一般為30秒左右一次，性能最好但是持久化最沒(méi)有保證，不推薦。      #在日志重寫(xiě)時(shí)，不進(jìn)行命令追加操作，而只是將其放在緩沖區(qū)里，避免與命令的追加造成DISK IO上的沖突。      #設(shè)置為yes表示rewrite期間對(duì)新寫(xiě)操作不fsync,暫時(shí)存在內(nèi)存中,等rewrite完成后再寫(xiě)入，默認(rèn)為no，建議yes      no-appendfsync-on-rewrite yes      #當(dāng)前AOF文件大小是上次日志重寫(xiě)得到AOF文件大小的二倍時(shí)，自動(dòng)啟動(dòng)新的日志重寫(xiě)過(guò)程。      auto-aof-rewrite-percentage 100      #當(dāng)前AOF文件啟動(dòng)新的日志重寫(xiě)過(guò)程的最小值，避免剛剛啟動(dòng)Reids時(shí)由于文件尺寸較小導(dǎo)致頻繁的重寫(xiě)。      auto-aof-rewrite-min-size 64mb

2.3 日志重寫(xiě)

AOF機(jī)制將客戶端的每一個(gè)寫(xiě)操作都追加到aof文件末尾，比如將一個(gè)key多次執(zhí)行incr,set命令,會(huì)寫(xiě)入多次命令到aof文件，aof文件會(huì)越來(lái)越大，部分核心業(yè)務(wù)每天的寫(xiě)入量有幾十G的大小。 

incr k1 1     set  k2 a     set  k2 b     incr k1 2     incr k1 3    set  k2 c     del  k3     ...     incr k1 100

恢復(fù)Redis實(shí)例時(shí)，加載非常大的aof文件耗時(shí)會(huì)很長(zhǎng)。為了解決這個(gè)問(wèn)題，Redis 支持aof文件重寫(xiě)--把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫(xiě)命令同步到新AOF文件中的過(guò)程。通過(guò)重寫(xiě)，可以生成一個(gè)最小的命令集合。比如上面的幾個(gè)命令可以合并為

incr k1 100    set  k2 c

寫(xiě)入數(shù)據(jù)的規(guī)則

1. 進(jìn)程內(nèi)過(guò)期的數(shù)據(jù)不用在寫(xiě)入

2. 舊AOF文件含有的無(wú)效命令 del k1, set a 1, set a 2。重寫(xiě)使用進(jìn)程內(nèi)的數(shù)據(jù)直接生成，aof文件就保留最新的命令集合。

3. 多條命令可以合并為一個(gè)命令，為了防止單個(gè)命令過(guò)大造成客戶端緩沖區(qū)溢出，對(duì)于list,set,hash,zset 等類型的操作，以64個(gè)元素為界拆分為多條。

觸發(fā)機(jī)制

1. 手動(dòng)觸發(fā) 執(zhí)行bgrewriteaof命令。

2. 根據(jù)配置自動(dòng)觸發(fā)

auto-aof-rewrite-min-size 表示運(yùn)行AOF重寫(xiě)是文件最小的大小。默認(rèn)64M，小于64M就會(huì)不自動(dòng)重寫(xiě)了。

auto-aof-rewrite-percentage 表示（aof_current_size- aof_base_size） / aof_base_size 的比值。

aof文件重寫(xiě)之后當(dāng)前文件大小增長(zhǎng)多少就觸發(fā)重寫(xiě)

自動(dòng)觸發(fā)時(shí)機(jī) :

aof_current_size>auto-aof-rewrite-min-size

&&

(aof_current_size - aof_base_size) /  aof_base_size >= auto-aof-rewrite-percentage

三 RDB VS AOF 對(duì)比

具體使用哪種持久化方式 ，下面是來(lái)自官方的建議：

通常，如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時(shí)使用兩種持久化方式。如果你可以接受災(zāi)難帶來(lái)的幾分鐘的數(shù)據(jù)丟失，那么你可以僅使用RDB。很多用戶僅使用了AOF，但是我們建議，既然RDB可以時(shí)不時(shí)的給數(shù)據(jù)做個(gè)完整的快照，并且提供更快的重啟，所以最好還是也使用RDB。

生產(chǎn)上的實(shí)例大多不會(huì)是單點(diǎn)，而是主從，也有利用slave作為持久化方式，同時(shí)滿足HA的需求。讀者朋友可以分享一下各自遇到的和 redis 持久化相關(guān)的問(wèn)題。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。

新聞名稱：Redis持久化的運(yùn)行機(jī)制和優(yōu)缺點(diǎn)是什么
文章路徑：http://aaarwkj.com/article44/jjgphe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、外貿(mào)網(wǎng)站建設(shè)、企業(yè)網(wǎng)站制作、移動(dòng)網(wǎng)站建設(shè)、用戶體驗(yàn)、靜態(tài)網(wǎng)站

廣告

聲明：本網(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)