文章目錄

為什么要持久化

RDB

RDB持久化方式RDB手動(dòng)觸發(fā)save命令bgsave觸發(fā)方式對(duì)比RDB自動(dòng)觸發(fā)查看配置RDB持久化命令RDB優(yōu)缺點(diǎn)RDB 優(yōu)點(diǎn)RDB缺點(diǎn)RDB故障恢復(fù)演示

AOF

AOF持久化always：everysec：no：AOF持久化恢復(fù)AOF的優(yōu)缺點(diǎn)優(yōu)點(diǎn)缺點(diǎn)AOF重寫AOF重寫的必要性重寫期間的數(shù)據(jù)一致性問題AOF文件覆蓋AOF重寫的阻塞性AOF重寫的觸發(fā)條件

RDB *VS* AOF

為什么要持久化

通常情況下redis的數(shù)據(jù)全部存儲(chǔ)在內(nèi)存中,數(shù)據(jù)庫一旦故障發(fā)生重啟數(shù)據(jù)會(huì)全部丟失，即使是在redis cluster或者redis sentinel模式下主從同步數(shù)據(jù)的恢復(fù)仍然需要一段時(shí)間混聊。

持久化功能在于能夠有效地避免因進(jìn)程退出造成的數(shù)據(jù)丟失問題，在下次重啟時(shí)利用之前持久化的文件即可實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。

開啟Redis持久化之后芬为，數(shù)據(jù)將存放到磁盤中，數(shù)據(jù)庫執(zhí)行增量同步的時(shí)間要遠(yuǎn)小于全量同步蟀悦。在生產(chǎn)環(huán)境下故障的數(shù)據(jù)恢復(fù)有著非常重要的作用!

Redis持久化有兩種方案：

RDB是一種快照式的數(shù)據(jù)存儲(chǔ)媚朦，它會(huì)周期性的保存當(dāng)前時(shí)間點(diǎn)Redis所有的數(shù)據(jù)到磁盤中。

AOF是一種追加式的存儲(chǔ)方式日戈，會(huì)實(shí)時(shí)的記錄Redis的寫操作到磁盤中询张。12

RDB

RDB持久化方式

RDB持久化把當(dāng)前進(jìn)程數(shù)據(jù)生成快照（.rdb）文件保存到硬盤的過程，有手動(dòng)觸發(fā)和自動(dòng)觸發(fā)浙炼。

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

手動(dòng)觸發(fā)有save和bgsave兩命令

save命令

該命令會(huì)阻塞當(dāng)前Redis服務(wù)器份氧，執(zhí)行save命令期間唯袄，Redis不能處理其他命令，直到RDB過程完成為止蜗帜。具體流程如下：

大家都不愛講這個(gè)恋拷，我就貼個(gè)圖吧。

執(zhí)行完成時(shí)候如果存在老的RDB文件厅缺，就把新的替代掉舊的蔬顾。我們的客戶端可能都是幾萬或者是幾十萬，這種方式顯然不可取湘捎。

在執(zhí)行redis-cli shutdown關(guān)閉redis服務(wù)時(shí)诀豁，如果沒有開啟AOF持久化，自動(dòng)執(zhí)行save窥妇。（多謝大佬“花里胡哨”指正）

bgsave觸發(fā)方式

Redis主進(jìn)程fork一個(gè)子進(jìn)程來創(chuàng)建臨時(shí)RDB存儲(chǔ)文件舷胜，創(chuàng)建文件完成后對(duì)這個(gè)臨時(shí)文件rename替換原先的RDB文件。RDB文件是一個(gè)單文件很適合數(shù)據(jù)的容災(zāi)備份與恢復(fù)秩伞，通過RDB文件恢復(fù)數(shù)據(jù)庫耗時(shí)較短逞带，通常1G的快照文件載入內(nèi)存只需20s左右。

對(duì)比

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

自動(dòng)觸發(fā)是由我們的配置文件來完成的纱新。

查看配置

save9001

save30010

save6010000

dbfilename"dump.rdb"

1234

前三行都是對(duì)觸發(fā)RDB的一個(gè)條件展氓， 如第一行表示每900秒鐘有一條數(shù)據(jù)被修改則觸發(fā)RDB，依次類推脸爱；只要一條滿足就會(huì)進(jìn)行RDB持久化遇汞；

第四行dbfilename指定了把內(nèi)存里的數(shù)據(jù)庫寫入本地文件的名稱，該文件是進(jìn)行壓縮后的二進(jìn)制文件簿废；

自動(dòng)觸發(fā)bgsave空入。

RDB持久化命令

命令：config set dir /usr/local //設(shè)置rdb文件保存路徑

備份：bgsave //將dump.rdb保存到usr/local下

恢復(fù)：將dump.rdb放到redis安裝目錄與redis.conf同級(jí)目錄，重啟redis即可

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

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

該說的前面都說了族檬，這里再加兩點(diǎn)：

RDB是Redis數(shù)據(jù)的一個(gè)非常緊湊的單文件時(shí)間點(diǎn)表示歪赢。RDB文件非常適合備份。例如单料，你可能希望在最近24小時(shí)內(nèi)每小時(shí)存檔一次RDB文件埋凯，并在30天內(nèi)每天保存一個(gè)RDB快照。這允許你在發(fā)生災(zāi)難時(shí)輕松恢復(fù)數(shù)據(jù)集的不同版本扫尖。

RDB非常適合災(zāi)難恢復(fù)白对，它是一個(gè)可以傳輸?shù)竭h(yuǎn)程數(shù)據(jù)中心或AmazonS3（可能是加密的）的壓縮文件。

與AOF相比换怖，RDB允許使用大數(shù)據(jù)集更快地重新啟動(dòng)甩恼。

RDB缺點(diǎn)

如果你需要在Redis停止工作的情況下（例如在斷電之后），將數(shù)據(jù)丟失的可能性降到最低，那么RDB是不好的条摸。你可以配置不同的保存點(diǎn)讓RDB至少可以保存5分鐘的數(shù)據(jù)悦污。因此，如果Redis由于任何原因沒有正確關(guān)閉而停止工作屈溉，你應(yīng)該做好好丟失最近幾分鐘的數(shù)據(jù)的心理準(zhǔn)備塞关。

RDB經(jīng)常需要fork()才能使用子進(jìn)程在磁盤上持久化。如果數(shù)據(jù)集很大子巾，fork()可能很耗時(shí)帆赢，如果數(shù)據(jù)集非常大，CPU性能不好线梗，可能會(huì)導(dǎo)致Redis停止為客戶機(jī)服務(wù)幾毫秒甚至一秒鐘椰于。

RDB故障恢復(fù)演示

刪除原有rdb文件，修改conf文件

客戶端操作數(shù)據(jù)

服務(wù)器又生成一個(gè)rdb文件仪搔，并追加日志

服務(wù)器將rdb文件備份后刪除

關(guān)閉客戶端

重啟服務(wù)器（忘了截）

再啟動(dòng)客戶端瘾婿，查詢數(shù)據(jù)，發(fā)現(xiàn)并沒有數(shù)據(jù)

以原備份rdb文件重啟服務(wù)器

重啟客戶端烤咧，查詢數(shù)據(jù)偏陪，數(shù)據(jù)依舊完好

AOF

針對(duì)RDB不適合實(shí)時(shí)持久化，redis提供了AOF持久化方式來解決

開啟方式就是在redis.conf設(shè)置：appendonly yes (默認(rèn)不開啟煮嫌，為no)

默認(rèn)文件名：appendfilename “appendonly.aof”

AOF持久化

當(dāng)開啟AOF后笛谦，服務(wù)端每執(zhí)行一次寫操作就會(huì)把該條命令追加到一個(gè)單獨(dú)的AOF緩沖區(qū)的末尾，然后把AOF緩沖區(qū)的內(nèi)容寫入AOF文件里昌阿，由于磁盤緩沖區(qū)的存在寫入AOF文件之后饥脑，并不代表數(shù)據(jù)已經(jīng)落盤了，而何時(shí)進(jìn)行文件同步則是根據(jù)配置的appendfsync來進(jìn)行配置：appendfsync有三個(gè)選項(xiàng)：always懦冰、everysec和no：

always：

服務(wù)器在每執(zhí)行一個(gè)事件就把AOF緩沖區(qū)的內(nèi)容強(qiáng)制性的寫入硬盤上的AOF文件里灶轰，保證了數(shù)據(jù)持久化的完整性，效率是最慢的但最安全的刷钢；

everysec：

服務(wù)端每隔一秒才會(huì)進(jìn)行一次文件同步把內(nèi)存緩沖區(qū)里的AOF緩存數(shù)據(jù)真正寫入AOF文件里笋颤，兼顧了效率和完整性，極端情況服務(wù)器宕機(jī)只會(huì)丟失一秒內(nèi)對(duì)Redis數(shù)據(jù)庫的寫操作内地；

no：

表示默認(rèn)系統(tǒng)的緩存區(qū)寫入磁盤的機(jī)制伴澄，不做程序強(qiáng)制，數(shù)據(jù)安全性和完整性差一些瓤鼻。

AOF持久化恢復(fù)

設(shè)置appendonly yes；

將appendonly.aof放到dir參數(shù)指定的目錄贤重；

啟動(dòng)Redis茬祷，Redis會(huì)自動(dòng)加載appendonly.aof文件。

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

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

AOF是通過保存Redis寫操作的命令來實(shí)現(xiàn)持久化并蝗，使用AOF來持久化祭犯，Redis數(shù)據(jù)的安全性將大幅提高秸妥，異常宕機(jī)情況下最多丟失1s的數(shù)據(jù)。AOF文件記錄了redis的寫操作沃粗，格式清晰粥惧，易于理解和修改，利于數(shù)據(jù)的重建最盅。

AOF日志是一個(gè)只附加的日志突雪，因此如果斷電，就不會(huì)出現(xiàn)查找或損壞問題涡贱。即使日志由于某種原因（磁盤已滿或其他原因）以半寫的命令結(jié)束咏删，redis check aof工具也可以輕松地修復(fù)它。

當(dāng)AOF太大時(shí)问词，Redis能夠在后臺(tái)自動(dòng)重寫AOF督函。重寫是完全安全的，因?yàn)楫?dāng)Redis繼續(xù)附加到舊文件時(shí)激挪，一個(gè)全新的文件會(huì)生成辰狡，只需創(chuàng)建當(dāng)前數(shù)據(jù)集所需的最少操作集，一旦第二個(gè)文件就緒垄分，Redis就會(huì)切換這兩個(gè)文件并開始附加到新文件中宛篇。

AOF以易于理解和解析的格式包含所有操作的日志。你甚至可以輕松導(dǎo)出AOF文件锋喜。

缺點(diǎn)

AOF文件通常比相同數(shù)據(jù)集的等效RDB文件大些己。

根據(jù)具體的fsync策略，AOF可能比RDB慢嘿般。

AOF重寫

AOF重寫的必要性

AOF比RDB文件更大段标，并且在存儲(chǔ)命令的過程中增長更快，為了壓縮AOF的持久化文件炉奴，Redis提供了重寫機(jī)制以此來實(shí)現(xiàn)控制AOF文件的增長逼庞。AOF重寫實(shí)現(xiàn)的理論基礎(chǔ)是這樣的：

執(zhí)行sethello world50次

最后執(zhí)行一次sethello china

最終對(duì)于AOF文件而言前面50次都是無意義的，AOF重寫就是將key只保存最后的狀態(tài)瞻赶。

123

重寫期間的數(shù)據(jù)一致性問題

的進(jìn)程在進(jìn)行 AOF 重寫期間赛糟， 主進(jìn)程還需要繼續(xù)處理命令， 而新的命令可能對(duì)現(xiàn)有的數(shù)據(jù)進(jìn)行修改砸逊， 會(huì)出現(xiàn)數(shù)據(jù)庫的數(shù)據(jù)和重寫后的 AOF 文件中的數(shù)據(jù)不一致璧南。因此Redis 增加了一個(gè) AOF 重寫緩存， 這個(gè)緩存在 fork 出子進(jìn)程之后開始啟用师逸， Redis 主進(jìn)程在接到新的寫命令之后司倚， 除了會(huì)將這個(gè)寫命令的協(xié)議內(nèi)容追加到現(xiàn)有的 AOF 文件之外， 還會(huì)追加到這個(gè)緩存中。

AOF文件覆蓋

當(dāng)子進(jìn)程完成 AOF 重寫之后向父進(jìn)程發(fā)送一個(gè)完成信號(hào)动知， 父進(jìn)程在接到完成信號(hào)之后會(huì)調(diào)用信號(hào)處理函數(shù)皿伺，完成以下工作：

將 AOF 重寫緩存中的內(nèi)容全部寫入到新 AOF 文件中對(duì)新的 AOF 文件進(jìn)行改名，覆蓋原有的 AOF 文件

1

AOF重寫的阻塞性

整個(gè) AOF 后臺(tái)重寫過程中只有最后寫入緩存和改名操作會(huì)造成主進(jìn)程阻塞盒粮， 在其他時(shí)候AOF 后臺(tái)重寫都不會(huì)對(duì)主進(jìn)程造成阻塞鸵鸥， 將 AOF 重寫對(duì)性能造成的影響降到了最低。

AOF重寫的觸發(fā)條件

AOF 重寫可以由用戶通過調(diào)用 BGREWRITEAOF 手動(dòng)觸發(fā)丹皱。服務(wù)器在 AOF 功能開啟的情況下妒穴，會(huì)維持以下三個(gè)變量：

當(dāng)前 AOF 文件大小

最后一次 重寫之后， AOF 文件大小的變量 AOF文件大小增長百分比123

每次當(dāng) serverCron 函數(shù)執(zhí)行時(shí)种呐， 它都會(huì)檢查以下條件是否全部滿足宰翅， 如果是的話， 就會(huì)觸發(fā)自動(dòng)的 AOF 重寫：

沒有 BGSAVE 命令在進(jìn)行 防止于RDB的沖突

沒有 BGREWRITEAOF 在進(jìn)行 防止和手動(dòng)AOF沖突當(dāng)前? AOF 文件大小至少大于設(shè)定值 基本要求 太小沒意義? 當(dāng)前 AOF 文件大小和最后一次 AOF 重寫后的大小之間的比率大于等于指定的增長百分比1234

RDB?VS?AOF

Redis恢復(fù)數(shù)據(jù)時(shí)會(huì)先檢查AOF文件是否存在爽室，如果不存在就嘗試加載RDB文件汁讼。

在實(shí)際生產(chǎn)環(huán)境中，根據(jù)數(shù)據(jù)量阔墩、應(yīng)用對(duì)數(shù)據(jù)的安全要求嘿架、預(yù)算限制等不同情況，會(huì)有各種各樣的持久化策略啸箫。如完全不使用任何持久化耸彪、使用RDB或AOF的一種，或同時(shí)開啟RDB和AOF持久化等忘苛。

PS：持久化的選擇必須與Redis的主從策略一起考慮蝉娜，因?yàn)橹鲝膹?fù)制與持久化同樣具有數(shù)據(jù)備份的功能，而且主機(jī)master和從機(jī)slave可以獨(dú)立的選擇持久化方案扎唾。