Redis持久化方案的示例分析

小編給大家分享一下Redis持久化方案的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

Redis支持RDB與AOF兩種持久化機(jī)制，持久化可以避免因進(jìn)程異常退出或down機(jī)導(dǎo)致的數(shù)據(jù)丟失問(wèn)題，在下次重啟時(shí)能利用之前的持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。

RDB持久化

RDB持久化即通過(guò)創(chuàng)建快照（壓縮的二進(jìn)制文件）的方式進(jìn)行持久化，保存某個(gè)時(shí)間點(diǎn)的全量數(shù)據(jù)。RDB持久化是Redis默認(rèn)的持久化方式。RDB持久化的觸發(fā)包括手動(dòng)觸發(fā)與自動(dòng)觸發(fā)兩種方式。

手動(dòng)觸發(fā)

• save， 在命令行執(zhí)行save命令，將以同步的方式創(chuàng)建rdb文件保存快照，會(huì)阻塞服務(wù)器的主進(jìn)程，生產(chǎn)環(huán)境中不要用

• bgsave, 在命令行執(zhí)行bgsave命令，將通過(guò)fork一個(gè)子進(jìn)程以異步的方式創(chuàng)建rdb文件保存快照，除了fork時(shí)有阻塞，子進(jìn)程在創(chuàng)建rdb文件時(shí)，主進(jìn)程可繼續(xù)處理請(qǐng)求
  

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

在redis.conf中配置 save m n 定時(shí)觸發(fā)，如 save 900 1表示在900s內(nèi)至少存在一次更新就觸發(fā)
主從復(fù)制時(shí)，如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，主節(jié)點(diǎn)自動(dòng)執(zhí)行bgsave生成RDB文件并發(fā)送給從節(jié)點(diǎn)
執(zhí)行debug reload命令重新加載Redis時(shí)
執(zhí)行shutdown且沒(méi)有開(kāi)啟AOF持久化
redis.conf中RDB持久化配置

 # 只要滿(mǎn)足下列條件之一，則會(huì)執(zhí)行bgsave命令
save 900 1 # 在900s內(nèi)存在至少一次寫(xiě)操作
save 300 10
save 60 10000
# 禁用RBD持久化，可在最后加 save ""

# 當(dāng)備份進(jìn)程出錯(cuò)時(shí)主進(jìn)程是否停止寫(xiě)入操作
stop-writes-on-bgsave-error yes
# 是否壓縮rdb文件 推薦no 相對(duì)于硬盤(pán)成本cpu資源更貴
rdbcompression no

AOF持久化

AOF（Append-Only-File）持久化即記錄所有變更數(shù)據(jù)庫(kù)狀態(tài)的指令，以append的形式追加保存到AOF文件中。在服務(wù)器下次啟動(dòng)時(shí)，就可以通過(guò)載入和執(zhí)行AOF文件中保存的命令，來(lái)還原服務(wù)器關(guān)閉前的數(shù)據(jù)庫(kù)狀態(tài)。

redis.conf中AOF持久化配置如下

# 默認(rèn)關(guān)閉AOF，若要開(kāi)啟將no改為yes
appendonly no

# append文件的名字
appendfilename "appendonly.aof"

# 每隔一秒將緩存區(qū)內(nèi)容寫(xiě)入文件 默認(rèn)開(kāi)啟的寫(xiě)入方式
appendfsync everysec

# 當(dāng)AOF文件大小的增長(zhǎng)率大于該配置項(xiàng)時(shí)自動(dòng)開(kāi)啟重寫(xiě)（這里指超過(guò)原大小的100%）。
auto-aof-rewrite-percentage 100

# 當(dāng)AOF文件大小大于該配置項(xiàng)時(shí)自動(dòng)開(kāi)啟重寫(xiě)
auto-aof-rewrite-min-size 64mb

AOF持久化的實(shí)現(xiàn)包括3個(gè)步驟:

• 命令追加：將命令追加到AOF緩沖區(qū)
  

• 文件寫(xiě)入：緩沖區(qū)內(nèi)容寫(xiě)到AOF文件
  

• 文件保存：AOF文件保存到磁盤(pán)
  

其中后兩步的頻率通過(guò)appendfsync來(lái)配置，appendfsync的選項(xiàng)包括

• always， 每執(zhí)行一個(gè)命令就保存一次，安全性最高，最多只丟失一個(gè)命令的數(shù)據(jù)，但是性能也最低（頻繁的磁盤(pán)IO）
  

• everysec，每一秒保存一次，推薦使用，在安全性與性能之間折中，最多丟失一秒的數(shù)據(jù)
  

• no， 依賴(lài)操作系統(tǒng)來(lái)執(zhí)行（一般大概30s一次的樣子），安全性最低，性能最高，丟失操作系統(tǒng)最后一次對(duì)AOF文件觸發(fā)SAVE操作之后的數(shù)據(jù)
  

AOF通過(guò)保存命令來(lái)持久化，隨著時(shí)間的推移，AOF文件會(huì)越來(lái)越大，Redis通過(guò)AOF文件重寫(xiě)來(lái)解決AOF文件不斷增大的問(wèn)題（可以減少文件的磁盤(pán)占有量，加快數(shù)據(jù)恢復(fù)的速度），原理如下：

調(diào)用fork，創(chuàng)建一個(gè)子進(jìn)程

子進(jìn)程讀取當(dāng)前數(shù)據(jù)庫(kù)的狀態(tài)來(lái)“重寫(xiě)”一個(gè)新的AOF文件（這里雖然叫“重寫(xiě)”，但實(shí)際并沒(méi)有對(duì)舊文件進(jìn)行任何讀取，而是根據(jù)數(shù)據(jù)庫(kù)的當(dāng)前狀態(tài)來(lái)形成指令）

主進(jìn)程持續(xù)將新的變動(dòng)同時(shí)寫(xiě)到AOF重寫(xiě)緩沖區(qū)與原來(lái)的AOF緩沖區(qū)中

主進(jìn)程獲取到子進(jìn)程重寫(xiě)AOF完成的信號(hào)，調(diào)用信號(hào)處理函數(shù)將AOF重寫(xiě)緩沖區(qū)內(nèi)容寫(xiě)入新的AOF文件中，并對(duì)新文件進(jìn)行重命名，原子地覆蓋原有AOF文件，完成新舊文件的替換

AOF的重寫(xiě)也分為手動(dòng)觸發(fā)與自動(dòng)觸發(fā)

• 手動(dòng)觸發(fā)： 直接調(diào)用bgrewriteaof命令

• 自動(dòng)觸發(fā)： 根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)確定自動(dòng)觸發(fā)時(shí)機(jī)。其中auto-aof-rewrite-min-size表示運(yùn)行AOF重寫(xiě)時(shí)文件最小體積，默認(rèn)為64MB。auto-aof-rewrite-percentage表示當(dāng)前AOF文件大小（aof_current_size）和上一次重寫(xiě)后AOF文件大?。╝of_base_size）的比值。自動(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

RDB與AOF兩種方式各有優(yōu)缺點(diǎn)。

• RDB的優(yōu)點(diǎn)：與AOF相比，RDB文件相對(duì)較小，恢復(fù)數(shù)據(jù)比較快（原因見(jiàn)數(shù)據(jù)恢復(fù)部分）

• RDB的缺點(diǎn)：服務(wù)器宕機(jī)，RBD方式會(huì)丟失掉上一次RDB持久化后的數(shù)據(jù)；使用bgsave fork子進(jìn)程時(shí)會(huì)耗費(fèi)內(nèi)存。

• AOF的優(yōu)點(diǎn)： AOF只是追加文件，對(duì)服務(wù)器性能影響較小，速度比RDB快，消耗內(nèi)存也少，同時(shí)可讀性高。

• AOF的缺點(diǎn)：生成的文件相對(duì)較大，即使通過(guò)AOF重寫(xiě)，仍然會(huì)比較大；恢復(fù)數(shù)據(jù)的速度比RDB慢。

數(shù)據(jù)庫(kù)的恢復(fù)

服務(wù)器啟動(dòng)時(shí)，如果沒(méi)有開(kāi)啟AOF持久化功能，則會(huì)自動(dòng)載入RDB文件，期間會(huì)阻塞主進(jìn)程。如果開(kāi)啟了AOF持久化功能，服務(wù)器則會(huì)優(yōu)先使用AOF文件來(lái)還原數(shù)據(jù)庫(kù)狀態(tài)，因?yàn)锳OF文件的更新頻率通常比RDB文件的更新頻率高，保存的數(shù)據(jù)更完整。

redis數(shù)據(jù)庫(kù)恢復(fù)的處理流程如下，

在數(shù)據(jù)恢復(fù)方面，RDB的啟動(dòng)時(shí)間會(huì)更短，原因有兩個(gè)：

RDB 文件中每一條數(shù)據(jù)只有一條記錄，不會(huì)像AOF日志那樣可能有一條數(shù)據(jù)的多次操作記錄。所以每條數(shù)據(jù)只需要寫(xiě)一次就行了，文件相對(duì)較小。

RDB 文件的存儲(chǔ)格式和Redis數(shù)據(jù)在內(nèi)存中的編碼格式是一致的，不需要再進(jìn)行數(shù)據(jù)編碼工作，所以在CPU消耗上要遠(yuǎn)小于AOF日志的加載。

但是在進(jìn)行RDB持久化時(shí)，fork出來(lái)進(jìn)行dump操作的子進(jìn)程會(huì)占用與父進(jìn)程一樣的內(nèi)存，采用的copy-on-write機(jī)制，對(duì)性能的影響和內(nèi)存的消耗都是比較大的。比如16G內(nèi)存，Redis已經(jīng)使用了10G，這時(shí)save的話(huà)會(huì)再生成10G，變成20G，大于系統(tǒng)的16G。這時(shí)候會(huì)發(fā)生交換，要是虛擬內(nèi)存不夠則會(huì)崩潰，導(dǎo)致數(shù)據(jù)丟失。所以在用redis的時(shí)候一定對(duì)系統(tǒng)內(nèi)存做好容量規(guī)劃。

RDB、AOF混合持久化

Redis從4.0版開(kāi)始支持RDB與AOF的混合持久化方案。首先由RDB定期完成內(nèi)存快照的備份，然后再由AOF完成兩次RDB之間的數(shù)據(jù)備份，由這兩部分共同構(gòu)成持久化文件。該方案的優(yōu)點(diǎn)是充分利用了RDB加載快、備份文件小及AOF盡可能不丟數(shù)據(jù)的特性。缺點(diǎn)是兼容性差，一旦開(kāi)啟了混合持久化，在4.0之前的版本都不識(shí)別該持久化文件，同時(shí)由于前部分是RDB格式，閱讀性較低。

開(kāi)啟混合持久化

aof-use-rdb-preamble yes

數(shù)據(jù)恢復(fù)加載過(guò)程就是先按照RDB進(jìn)行加載，然后把AOF命令追加寫(xiě)入。

持久化方案的建議

如果Redis只是用來(lái)做緩存服務(wù)器，比如數(shù)據(jù)庫(kù)查詢(xún)數(shù)據(jù)后緩存，那可以不用考慮持久化，因?yàn)榫彺娣?wù)失效還能再?gòu)臄?shù)據(jù)庫(kù)獲取恢復(fù)。

如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時(shí)使用兩種持久化方式。如果你可以接受災(zāi)難帶來(lái)的幾分鐘的數(shù)據(jù)丟失，那么可以?xún)H使用RDB。

通常的設(shè)計(jì)思路是利用主從復(fù)制機(jī)制來(lái)彌補(bǔ)持久化時(shí)性能上的影響。即Master上RDB、AOF都不做，保證Master的讀寫(xiě)性能，而Slave上則同時(shí)開(kāi)啟RDB和AOF（或4.0以上版本的混合持久化方式）來(lái)進(jìn)行持久化，保證數(shù)據(jù)的安全性。

以上是“Redis持久化方案的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！