共計(jì) 3605 個(gè)字符，預(yù)計(jì)需要花費(fèi) 10 分鐘才能閱讀完成。
Redis 持久化的運(yùn)行機(jī)制和優(yōu)缺點(diǎn)是什么，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面丸趣 TV 小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。
前言
大家都知道 Redis 一個(gè)內(nèi)存數(shù)據(jù)庫(kù), 它支持 2 種持久化方式：RDB(Snapshot 內(nèi)存快照)，AOF(append only file)。持久化功能將內(nèi)存中的數(shù)據(jù)同步到磁盤來避免 Redis 發(fā)生異常導(dǎo)致數(shù)據(jù)丟失的情況。當(dāng) Redis 實(shí)例重啟時(shí)，即可利用之前持久化的文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。
接下來，丸趣 TV 小編介紹兩種持久化的運(yùn)行機(jī)制和優(yōu)缺點(diǎn)。
一 RDB
RDB 是默認(rèn)的持久化方式，按照一定的策略周期性的將內(nèi)存中的數(shù)據(jù)生成快照保存到磁盤。
每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次，并不 是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫操作比較多，必然會(huì)引起大量的磁盤 io 操作，可能會(huì)嚴(yán)重影響性能。
1.1 快照持久化過程
1.2 觸發(fā)機(jī)制
1. save 命令
當(dāng)客戶端向 Redis server 發(fā)送 save 命令請(qǐng)求進(jìn)行持久化時(shí)，由于 Redis 是用一個(gè)主線程來處理所有,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á)到一條寫命令 save 900 1 # 300s 內(nèi)至少達(dá)至 10 條寫命令 save 300 10 # 60s 內(nèi)至少達(dá)到 10000 條寫命令 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í)，如果沒有開啟 AOF 持久化功能，系統(tǒng)會(huì)自動(dòng)執(zhí)行 bgsave 命令。執(zhí)行 debug reload 命令重新加載 Redis 時(shí)，也會(huì)自動(dòng)觸發(fā) save 操作。
1.3 相關(guān)參數(shù)
# 持久化 rdb 文件遇到問題時(shí)，主進(jìn)程是否接受寫入，yes 表示停止寫入，如果是 no 表示 redis 繼續(xù)提供服務(wù)。 stop-writes-on-bgsave-error yes # 在進(jìn)行快照鏡像時(shí), 是否進(jìn)行壓縮。yes: 壓縮，但是需要一些 cpu 的消耗。no: 不壓縮，需要更多的磁盤空間。 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/redis1.4 RDB 的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)
RDB 文件小，非常適合定時(shí)備份，用于災(zāi)難恢復(fù)。
因?yàn)?RDB 文件中直接存儲(chǔ)的是內(nèi)存數(shù)據(jù)，而 AOF 文件中存儲(chǔ)的是一條條命令，需要應(yīng)用命令。Redis 加載 RDB 文件的速度比 AOF 快很多。
缺點(diǎn)
RDB 持久化方式不能做到實(shí)時(shí) / 秒級(jí)持久化。實(shí)時(shí)持久化要全量刷內(nèi)存到磁盤，成本太高。每秒 fork 子進(jìn)程也會(huì)阻塞主進(jìn)程，影響性能。
RDB 文件是二進(jìn)制文件，隨著 Redis 不斷迭代有多個(gè) rdb 文件的版本，不支持跨版本兼容。老的 Redis 無法識(shí)別新的 RDB 文件格式。
二 AOF
AOF(Append-only file) 針對(duì) RDB 的缺點(diǎn)做了優(yōu)化，在使用 AOF 持久化方式時(shí)，Redis 會(huì)將每一個(gè)收到的寫操作命令都通過 Write 函數(shù)追加到文件最后，類似于 MySQL 的 binlog。當(dāng) Redis 重啟時(shí)會(huì)通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個(gè)數(shù)據(jù)庫(kù)的內(nèi)容。
2.1 AOF 持久化過程
1. 客戶端發(fā)出 bgrewriteaof 命令。
2. redis 主進(jìn)程 fork 子進(jìn)程。
3. 父進(jìn)程繼續(xù)處理 client 請(qǐng)求，除了把寫命令寫入到原來的 aof 文件中。同時(shí)把收到的寫命令緩存到 AOF 重寫緩沖區(qū)。這樣就能保證如果子進(jìn)程重寫失敗的話并不會(huì)出問題。
4. 子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新 AOF 文件中。
5. 當(dāng)子進(jìn)程把內(nèi)存快照寫入臨時(shí)文件中后，子進(jìn)程發(fā)信號(hào)通知父進(jìn)程。然后父進(jìn)程把緩存的寫命令也寫入到臨時(shí)文件。
6. 現(xiàn)在父進(jìn)程可以使用臨時(shí)文件替換老的 aof 文件，并重命名，后面收到的寫命令也開始往新的 aof 文件中追加。
2.2 相關(guān)參數(shù)
# 是否開啟 AOF，默認(rèn)關(guān)閉 appendonly yes # 指定 AOF 文件名 appendfilename appendonly.aof # Redis 支持三種刷寫模式： # appendfsync always #每次收到寫命令就立即強(qiáng)制寫入磁盤，類似 MySQL 的 sync_binlog=1, 是最安全的。但該模式下速度也是最慢的，一般不推薦使用。 appendfsync everysec #每秒鐘強(qiáng)制寫入磁盤一次，在性能和持久化方面做平衡，推薦該方式。 # appendfsync no #完全依賴 OS 的寫入，一般為 30 秒左右一次，性能最好但是持久化最沒有保證，不推薦。 #在日志重寫時(shí)，不進(jìn)行命令追加操作，而只是將其放在緩沖區(qū)里，避免與命令的追加造成 DISK IO 上的沖突。 #設(shè)置為 yes 表示 rewrite 期間對(duì)新寫操作不 fsync, 暫時(shí)存在內(nèi)存中, 等 rewrite 完成后再寫入，默認(rèn)為 no，建議 yes no-appendfsync-on-rewrite yes #當(dāng)前 AOF 文件大小是上次日志重寫得到 AOF 文件大小的二倍時(shí)，自動(dòng)啟動(dòng)新的日志重寫過程。 auto-aof-rewrite-percentage 100 # 當(dāng)前 AOF 文件啟動(dòng)新的日志重寫過程的最小值，避免剛剛啟動(dòng) Reids 時(shí)由于文件尺寸較小導(dǎo)致頻繁的重寫。 auto-aof-rewrite-min-size 64mb2.3 日志重寫
AOF 機(jī)制將客戶端的每一個(gè)寫操作都追加到 aof 文件末尾，比如將一個(gè) key 多次執(zhí)行 incr,set 命令, 會(huì)寫入多次命令到 aof 文件，aof 文件會(huì)越來越大，部分核心業(yè)務(wù)每天的寫入量有幾十 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è)問題，Redis 支持 aof 文件重寫 – 把 Redis 進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新 AOF 文件中的過程。通過重寫，可以生成一個(gè)最小的命令集合。比如上面的幾個(gè)命令可以合并為
incr k1 100 set k2 c寫入數(shù)據(jù)的規(guī)則
1. 進(jìn)程內(nèi)過期的數(shù)據(jù)不用在寫入
2. 舊 AOF 文件含有的無效命令 del k1, set a 1, set a 2。重寫使用進(jìn)程內(nèi)的數(shù)據(jù)直接生成，aof 文件就保留最新的命令集合。
3. 多條命令可以合并為一個(gè)命令，為了防止單個(gè)命令過大造成客戶端緩沖區(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 重寫是文件最小的大小。默認(rèn) 64M，小于 64M 就會(huì)不自動(dòng)重寫了。
auto-aof-rewrite-percentage 表示（aof_current_size- aof_base_size）/ aof_base_size 的比值。
aof 文件重寫之后當(dāng)前文件大小增長(zhǎng)多少就觸發(fā)重寫
自動(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ì)比
具體使用哪種持久化方式，下面是來自官方的建議：
通常，如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時(shí)使用兩種持久化方式。如果你可以接受災(zāi)難帶來的幾分鐘的數(shù)據(jù)丟失，那么你可以僅使用 RDB。很多用戶僅使用了 AOF，但是我們建議，既然 RDB 可以時(shí)不時(shí)的給數(shù)據(jù)做個(gè)完整的快照，并且提供更快的重啟，所以最好還是也使用 RDB。
生產(chǎn)上的實(shí)例大多不會(huì)是單點(diǎn)，而是主從，也有利用 slave 作為持久化方式，同時(shí)滿足 HA 的需求。讀者朋友可以分享一下各自遇到的和 redis 持久化相關(guān)的問題。
看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道，感謝您對(duì)丸趣 TV 的支持。
