大家都知道，Redis之所以性能好，讀寫快，是因?yàn)镽edis是一個(gè)內(nèi)存數(shù)據(jù)庫，它的操作都幾乎基于內(nèi)存。但是內(nèi)存型數(shù)據(jù)庫有一個(gè)很大的弊端，就是當(dāng)數(shù)據(jù)庫進(jìn)程崩潰或系統(tǒng)重啟的時(shí)候，如果內(nèi)存數(shù)據(jù)不保存的話，里面的數(shù)據(jù)就會(huì)丟失不見了。這樣的數(shù)據(jù)庫并不是一個(gè)可靠的數(shù)據(jù)庫。

站在用戶的角度思考問題，與客戶深入溝通，找到大名網(wǎng)站設(shè)計(jì)與大名網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、主機(jī)域名、虛擬主機(jī)、企業(yè)郵箱。業(yè)務(wù)覆蓋大名地區(qū)。

所以數(shù)據(jù)的持久化是內(nèi)存型數(shù)據(jù)庫的重中之重。它不僅提供數(shù)據(jù)保存硬盤的功能，還可以借此用硬盤容量擴(kuò)展數(shù)據(jù)存儲(chǔ)空間，使得Redis的可以存儲(chǔ)超過機(jī)器本身內(nèi)存大小的數(shù)據(jù)。

Redis對(duì)于數(shù)據(jù)持久化提供了兩種持久化的方案，RDB與AOF。它們的原理和使用場景都大不相同，下面我們來詳細(xì)地了解下。

RDB——數(shù)據(jù)快照（Snapshot）

RDB，提供一個(gè)某個(gè)時(shí)間點(diǎn)的數(shù)據(jù)的Snapshot，保存在RDB文件中。它可以通過SAVE/BGSAVE命令手動(dòng)執(zhí)行，把數(shù)據(jù)Snapshot寫到RDB文件，也可以通過配置，定時(shí)執(zhí)行。

Redis也可以通過加載RDB文件，把數(shù)據(jù)從磁盤加載讀取到Redis中。

RDB文件創(chuàng)建

連上Redis，設(shè)值一些值，然后執(zhí)行SAVE命令。

然后可以查看下redis.conf的持久化工作目錄。進(jìn)入目錄可以看到保存了一個(gè)dump.rdb文件。該文件是一個(gè)二進(jìn)制文件，無法直接正常打開。

至于SAVE/BGSAVE的區(qū)別，就是前置是阻塞執(zhí)行，此時(shí)服務(wù)不會(huì)接受請(qǐng)求，后者是Fork一個(gè)子進(jìn)程出來，由該進(jìn)程去執(zhí)行保存RDB文件的操作，不影響用戶請(qǐng)求。

P.S. Redis是單進(jìn)程的，所以BGSAVE只能Fork一個(gè)子進(jìn)程，而不是創(chuàng)建一個(gè)線程處理。

以上是手動(dòng)執(zhí)行的過程。但在生產(chǎn)我們很少會(huì)手動(dòng)登上服務(wù)去執(zhí)行操作，所以更多的時(shí)候是依賴Redis的配置，定時(shí)保存RDB文件。

打開redis.conf配置文件，找到SNAPSHOTTING的配置，Save Point的設(shè)置。

圖中的配置意思是，當(dāng)至少有一個(gè)key變更時(shí)，900秒后會(huì)執(zhí)行一次SAVE。其他配置同理，有10次變更，300秒后保存一次.....

在Redis中，這個(gè)自動(dòng)保存RDB的功能是默認(rèn)開啟的。

RDB文件加載

先kill掉Redis進(jìn)程，再重新啟動(dòng)Redis Server，會(huì)發(fā)現(xiàn)日志會(huì)有這樣的一行，

并且Redis中，依然有之前設(shè)置的三個(gè)值。說明Redis在啟動(dòng)的時(shí)候，會(huì)加載數(shù)據(jù)初始化。

不過，這里加載的初始化數(shù)據(jù)不一定是RDB的。如果Redis開啟了AOF，會(huì)優(yōu)先從AOF初始化數(shù)據(jù)，否則才會(huì)加載RDB的數(shù)據(jù)。

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

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

1. RDB是某一時(shí)間點(diǎn)的快照，是一個(gè)緊湊的單文件，更多用于數(shù)據(jù)備份。可以按每小時(shí)或每日來備份，方便從不同的版本恢復(fù)數(shù)據(jù)。
2. 單文件容易傳輸?shù)竭h(yuǎn)程服務(wù)做故障恢復(fù)。
3. RDB可以Fork子進(jìn)程進(jìn)行持久化，使Redis可以更好地處理用戶請(qǐng)求
4. 在大量數(shù)據(jù)的情況下，RDB相比較于AOF會(huì)更快的加載。

缺點(diǎn)：

1. 如果Redis不及時(shí)保存RDB文件，會(huì)造成數(shù)據(jù)的丟失。例如系統(tǒng)突然斷電，但未來得及保存數(shù)據(jù)。即使你設(shè)置更多的Save point，也無法保證100%的數(shù)據(jù)不丟失。
2. RDB經(jīng)常需要fork子進(jìn)程去執(zhí)行，但如果再大量數(shù)據(jù)的情況下，這個(gè)fork操作會(huì)非常耗CPU資源的。對(duì)比AOF雖然也是fork，但是它的數(shù)據(jù)保存處理是可以控制的，不需要全量保存。

AOF——日志追加（Append-Only）

Redis的另外一種持久化方案就是AOF，Append Only File。AOF相當(dāng)于一個(gè)操作的日志記錄，每次對(duì)于數(shù)據(jù)的變更都會(huì)記錄追加到AOF日志。當(dāng)服務(wù)啟動(dòng)的時(shí)候就會(huì)讀這些操作日志，重新執(zhí)行一次操作，從而恢復(fù)原始數(shù)據(jù)。

AOF啟用

AOF默認(rèn)是關(guān)閉的。打開redis.conf配置文件，找到appendonly no改成appendonly yes。

AOF和RDB是可以共存的，只要保存的文件名不沖突。

AOF fsync同步規(guī)則

配置文件往下拉，看到fsync的配置。

fsync()是一個(gè)系統(tǒng)調(diào)用函數(shù)，告訴操作系統(tǒng)把數(shù)據(jù)寫到硬盤上，而不是緩存更多數(shù)據(jù)才寫到硬盤。這樣的調(diào)用可以及時(shí)保存數(shù)據(jù)到硬盤上。

Redis提供了三種fsync的調(diào)用方式

• appendfsync always，每次操作記錄都同步到硬盤上，最低效，最安全。
• appendfsync everysec，每秒執(zhí)行一次把操作記錄同步到硬盤上。默認(rèn)選項(xiàng)。
• appendfsync no，不執(zhí)行fysnc調(diào)用，讓操作系統(tǒng)自動(dòng)操作把緩存數(shù)據(jù)寫到硬盤上，不可靠，但最快。

AOF文件格式解析

開啟AOF后，會(huì)再工作目錄看到appendonly.aof文件。

在客戶端上執(zhí)行一些命令后，打開AOF文件，可以觀察到有對(duì)應(yīng)的操作的記錄日志。

文件解析說明：

• *，表示命令的參數(shù)個(gè)數(shù)，例如set a 1是三個(gè)參數(shù)，所以是*3
• $，表示參數(shù)的字節(jié)數(shù)，例如set這個(gè)參數(shù)是三字節(jié)，所以是$3，key值a是一個(gè)字節(jié)，所以是$1
• 無符號(hào)，表示是參數(shù)的數(shù)據(jù)，例如set,a,1就是具體的數(shù)據(jù)

日志重寫

AOF雖然比RDB更可靠，但缺點(diǎn)也是比較明顯的，就是每次寫操作都要把操作日志寫到文件上，這樣會(huì)導(dǎo)致文件非常冗余。

假若你要自增一個(gè)計(jì)數(shù)器100次，如果不重寫，AOF文件就就會(huì)有這100次的自增記錄，如INCR a。如果執(zhí)行了日志重寫，那么文件只會(huì)保留set a 100而不是100條INCR a。這樣擁有相同的結(jié)果，但可以大大減少AOF的文件大小，并且可以讓AOF載入的時(shí)候提升載入的效率。

看回redis.conf配置，有兩項(xiàng)控制rewrite的選項(xiàng)。

• auto-aof-rewrite-percentage 100，當(dāng)文件增長100%（一倍）時(shí)候，自動(dòng)重寫。
• auto-aof-rewrite-min-size 64mb，日志重寫最小文件大小，如果小于該大小，不會(huì)自動(dòng)重寫。

來實(shí)驗(yàn)一下重寫的結(jié)果，我們先設(shè)定一個(gè)a值，然后自增多次，查看AOF文件內(nèi)容。里面有很多INCR的語句記錄

然后我們手動(dòng)執(zhí)行下BGREWRITEOF，執(zhí)行日志重寫。

可以看到，多個(gè)incr語句，變成了一個(gè)set a 6語句，減少了5個(gè)incr a語句的操作日志。

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

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

1. AOF可以設(shè)置 完全不同步、每秒同步、每次操作同，默認(rèn)是每秒同步。因?yàn)锳OF是操作指令的追加，所以可以頻繁的大量的同步。
2. AOF文件是一個(gè)值追加日志的文件，即使服務(wù)宕機(jī)為寫入完整的命令，也可以通過redis-check-aof工具修復(fù)這些問題。
3. 如果AOF文件過大，Redis會(huì)在后臺(tái)自動(dòng)地重寫AOF文件。重寫后會(huì)使AOF文件壓縮到最小所需的指令集。
4. AOF文件是有序保存數(shù)據(jù)庫的所有寫入操作，易讀，易分析。即使如果不小心誤操作數(shù)據(jù)庫，也很容易找出錯(cuò)誤指令，恢復(fù)到某個(gè)數(shù)據(jù)節(jié)點(diǎn)。例如不小心FLUSHALL，可以非常容易恢復(fù)到執(zhí)行命令之前。

缺點(diǎn)

1. 相同數(shù)據(jù)量下，AOF的文件通常體積會(huì)比RDB大。因?yàn)锳OF是存指令的，而RDB是所有指令的結(jié)果快照。但AOF在日志重寫后會(huì)壓縮一些空間。
2. 在大量寫入和載入的時(shí)候，AOF的效率會(huì)比RDB低。因?yàn)榇罅繉懭?，AOF會(huì)執(zhí)行更多的保存命令，載入的時(shí)候也需要大量的重執(zhí)行命令來得到最后的結(jié)果。RDB對(duì)此更有優(yōu)勢。

如何選擇

以上已經(jīng)基本了解過RDB和AOF的使用、基本原理以及對(duì)應(yīng)的優(yōu)缺點(diǎn)。那么在實(shí)際當(dāng)中，我們到底怎么去選擇用哪種持久化方式呢？

一般來說，不考慮硬盤大小，最安全的做法是RDB與AOF同時(shí)使用，即使AOF損壞無法修復(fù)，還可以用RDB來恢復(fù)數(shù)據(jù)。

如果Redis的數(shù)據(jù)在你的服務(wù)中并不是必要的數(shù)據(jù)，例如只是當(dāng)簡單的緩存，沒有緩存也不會(huì)造成緩存雪崩。說明數(shù)據(jù)的安全可靠性并不是首要考慮范圍內(nèi)，那么單獨(dú)只使用RDB就可以了。

不推薦單獨(dú)使用AOF，因?yàn)锳OF對(duì)于數(shù)據(jù)的恢復(fù)載入來說，比RDB慢。并且Redis官方也說明了，AOF有一個(gè)罕見的bug。出了問題無法很好的解決。所以使用AOF的時(shí)候，最好還是有RDB作為數(shù)據(jù)備份。

根據(jù)官方的意愿描述，在未來可能會(huì)有一種RDB與AOF相結(jié)合的持久化模型。到時(shí)Redis持久化就不再如此麻煩費(fèi)勁了，我們拭目以待吧。

---

更多技術(shù)文章、精彩干貨，請(qǐng)關(guān)注
博客：zackku.com
微信公眾號(hào)：Zack說碼

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

網(wǎng)頁題目：進(jìn)階的Redis之?dāng)?shù)據(jù)持久化RDB與AOF-創(chuàng)新互聯(lián)
網(wǎng)頁地址：http://jinyejixie.com/article22/dphccc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、用戶體驗(yàn)、小程序開發(fā)、企業(yè)網(wǎng)站制作、服務(wù)器托管、Google

廣告

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