共計 4535 個字符，預(yù)計需要花費 12 分鐘才能閱讀完成。

這篇文章主要介紹“怎么使用快照和 AOF 將 Redis 數(shù)據(jù)持久化到硬盤中”，在日常操作中，相信很多人在怎么使用快照和 AOF 將 Redis 數(shù)據(jù)持久化到硬盤中問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么使用快照和 AOF 將 Redis 數(shù)據(jù)持久化到硬盤中”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學(xué)習(xí)吧！

前言

我們知道 Redis 是一款內(nèi)存服務(wù)器，就算我們對自己的服務(wù)器足夠的信任，不會出現(xiàn)任何軟件或者硬件的故障，但也會有可能出現(xiàn)突然斷電等情況，造成 Redis 服務(wù)器中的數(shù)據(jù)失效。因此，我們需要向傳統(tǒng)的關(guān)系型數(shù)據(jù)庫一樣對數(shù)據(jù)進(jìn)行備份，將 Redis 在內(nèi)存中的數(shù)據(jù)持久化到硬盤等非易失性介質(zhì)中，來保證數(shù)據(jù)的可靠性。

將 Redis 內(nèi)存服務(wù)器中的數(shù)據(jù)持久化到硬盤等介質(zhì)中的一個好處就是，使得我們的服務(wù)器在重啟之后還可以重用以前的數(shù)據(jù)，或者是為了防止系統(tǒng)出現(xiàn)故障而將數(shù)據(jù)備份到一個遠(yuǎn)程的位置。

還有一些場景，例如：

 對于一些需要進(jìn)行大量計算而得到的數(shù)據(jù)，放置在 Redis 服務(wù)器，我們就有必要對其進(jìn)行數(shù)據(jù)的持久化，如果需要對數(shù)據(jù)進(jìn)行恢復(fù)的時候，我們就不需進(jìn)行重新的計算，只需要簡單的將這臺機器上的數(shù)據(jù)復(fù)制到另一臺需要恢復(fù)的 Redis 服務(wù)器就可以了。

Redis 給我們提供了兩種不同方式的持久化方法：快照（Snapshotting）和 只追加文件（append-only-file）。

（1）名詞簡介

快照（RDB）：就是我們俗稱的備份，他可以在定期內(nèi)對數(shù)據(jù)進(jìn)行備份，將 Redis 服務(wù)器中的數(shù)據(jù)持久化到硬盤中；

只追加文件（AOF）：他會在執(zhí)行寫命令的時候，將執(zhí)行的寫命令復(fù)制到硬盤里面，后期恢復(fù)的時候，只需要重新執(zhí)行一下這個寫命令就可以了。類似于我們的 MySQL 數(shù)據(jù)庫在進(jìn)行主從復(fù)制的時候，使用的是 binlog 二進(jìn)制文件，同樣的是執(zhí)行一遍寫命令；

（2）快照持久化通用的配置：

save 60 1000 #60 秒時間內(nèi)有 1000 次寫入操作的時候執(zhí)行快照的創(chuàng)建 stop-writes-on-bgsave-error no #創(chuàng)建快照失敗的時候是否仍然繼續(xù)執(zhí)行寫命令 rdbcompression yes #是否對快照文件進(jìn)行壓縮 dbfilename dump.rdb #如何命名硬盤上的快照文件 dir ./ # 快照所保存的位置 

（3）AOP 持久化配置：

appendonly no #是否使用 AOF 持久化 appendfsync everysec #多久執(zhí)行一次將寫入內(nèi)容同步到硬盤上 no-appendfsync-on-rewrite no #對 AOF 進(jìn)行壓縮的時候能否執(zhí)行同步操作 auto-aof-rewrite-percentage 100 #多久執(zhí)行一次 AOF 壓縮 auto-aof-rewrite-min-size 64mb # 多久執(zhí)行一次 AOF 壓縮 dir ./ #AOF 所保存的位置 

需要注意的是：這兩種持久化的方式既可以單獨的使用，也可以同時使用，具體選擇哪種方式需要根據(jù)具體的情況進(jìn)行選擇。

快照持久化

快照就是我們所說的備份。用戶可以將 Redis 內(nèi)存中的數(shù)據(jù)在某一個時間點進(jìn)行備份，在創(chuàng)建快照之后，用戶可以對快照進(jìn)行備份。通常情況下，為了防止單臺服務(wù)器出現(xiàn)故障造成所有數(shù)據(jù)的丟失，我們還可以將快照復(fù)制到其他服務(wù)器，創(chuàng)建具有相同數(shù)據(jù)的數(shù)據(jù)副本，這樣的話，數(shù)據(jù)恢復(fù)的時候或者服務(wù)器重啟的時候就可以使用這些快照信息進(jìn)行數(shù)據(jù)的恢復(fù)，也可以防止單臺服務(wù)器出現(xiàn)故障的時候造成數(shù)據(jù)的丟失。

但是，沒我們還需要注意的是，創(chuàng)建快照的方式，并不能完全保證我們的數(shù)據(jù)不丟失，這個大家可以很好的理解，因為快照的創(chuàng)建時定時的，并不是每一次更新操作都會創(chuàng)建一個快照的。系統(tǒng)發(fā)生崩潰的時候，用戶將丟失最近一次生成快照之后更改的所有數(shù)據(jù)。因此，快照持久化的方式只適合于數(shù)據(jù)不經(jīng)常修改或者丟失部分?jǐn)?shù)據(jù)影響不大的場景。

一、創(chuàng)建快照的方式：

（1）客戶端通過向 Redis 發(fā)送 BGSAVE 命令來創(chuàng)建快照。

使用 BGSAVE 的時候，Redis 會調(diào)用 fork 來創(chuàng)建一個子進(jìn)程，然后子進(jìn)程負(fù)責(zé)將快照寫到硬盤中，而父進(jìn)程則繼續(xù)處理命令請求。

使用場景：

如果用戶使用了 save 設(shè)置，例如：save 60 1000 , 那么從 Redis 最近一次創(chuàng)建快照之后開始計算，當(dāng)“60 秒之內(nèi)有 1000 次寫入操作”這個條件滿足的時候，Redis 就會自動觸發(fā) BGSAVE 命令。

如果用戶使用了多個 save 設(shè)置，那么當(dāng)任意一個 save 配置滿足條件的時候，Redis 都會觸發(fā)一次 BGSAVE 命令。

（2）客戶端通過向 Redis 發(fā)送 SAVE 命令來創(chuàng)建快照。

接收到 SAVE 命令的 Redis 服務(wù)器在快照創(chuàng)建完畢之前將不再響應(yīng)任何其他命令的請求。SAVE 命令并不常用，我們通常只在沒有足夠的內(nèi)存去執(zhí)行 BGSAVE 命令的時候才會使用 SAVE 命令，或者即使等待持久化操作執(zhí)行完畢也無所謂的情況下，才會使用這個命令；

使用場景：

當(dāng) Redis 通過 SHUTDOWN 命令接收到關(guān)閉服務(wù)器的請求時，或者接收到標(biāo)準(zhǔn)的 TERM 信號時，會執(zhí)行一次 SAVE 命令，阻塞所有的客戶端，不再執(zhí)行客戶端發(fā)送的任何命令，并且在執(zhí)行完 SAVE 命令之后關(guān)閉服務(wù)器。

二、使用快照持久化注意事項：

我們在使用快照的方式來保存數(shù)據(jù)的時候，如果 Redis 服務(wù)器中的數(shù)據(jù)量比較小的話，例如只有幾個 GB 的時候。Redis 會創(chuàng)建子進(jìn)程并將數(shù)據(jù)保存到硬盤里邊，生成快照所需的時間比讀取數(shù)據(jù)所需要的時間還要短。

但是，隨著數(shù)據(jù)的增大，Redis 占用的內(nèi)存越來越大的時候，BGSAVE 在創(chuàng)建子進(jìn)程的時候消耗的時間也會越來越多，如果 Redis 服務(wù)器所剩下的內(nèi)存不多的時候，這行 BGSAVE 命令會使得系統(tǒng)長時間地停頓，還有可能導(dǎo)致服務(wù)器無法使用。

各虛擬機類別，創(chuàng)建子線程所耗時間：

因此，為了防止 Redis 因為創(chuàng)建子進(jìn)程的時候出現(xiàn)停頓，我們可以考慮關(guān)閉自動保存，轉(zhuǎn)而通過手動的方式發(fā)送 BGSAVE 或者 SAVE 來進(jìn)行持久化，

手動的方式發(fā)送 BGSAVE 也會出現(xiàn)停頓的現(xiàn)象，但是我們可以控制發(fā)送該命令的時間來控制出現(xiàn)停頓的時候不影響具體的業(yè)務(wù)請求。

另外，值得注意的是，在使用 SAVE 命令的時候，雖然會一直阻塞 Redis 直到快照生成完畢，但是其不需要創(chuàng)建子進(jìn)程，所以不會向 BGSAVE 一樣，因為創(chuàng)建子進(jìn)程而導(dǎo)致 Redis 停頓。也正因為如此，SAVE 創(chuàng)建快照的速度要比 BGSAVE 創(chuàng)建快照的速度更快一些。

創(chuàng)建快照的時候，我們可以在業(yè)務(wù)請求，比較少的時候，比如凌晨三、四點，通過手寫腳本的方式，定時執(zhí)行。

AOF 持久化

AOF 持久化會將被執(zhí)行的寫命令寫到 AOF 文件的末尾，以此來記錄數(shù)據(jù)發(fā)生的變化。這樣，我們在恢復(fù)數(shù)據(jù)的時候，只需要從頭到尾的執(zhí)行一下 AOF 文件即可恢復(fù)數(shù)據(jù)。

一、打開 AOF 持久化選項

我們可以通過使用如下命令打開 AOF：

appendonly yes

我們，通過如下命令來配置 AOF 文件的同步頻率：

appendfsync everysec/always/no

二、appendfsync 同步頻率的區(qū)別

appendfsync 同步頻率的區(qū)別如下圖：

（1）always 的方式固然可以對沒一條數(shù)據(jù)進(jìn)行很好的保存，但是這種同步策略需要對硬盤進(jìn)行大量的寫操作，所以 Redis 處理命令的速度會受到硬盤性能的限制。

普通的硬盤每秒鐘只能處理大約 200 個寫命令，使用固態(tài)硬盤 SSD 每秒可以處理幾萬個寫命令，但是每次只寫一個命令，這種只能怪不斷地寫入很少量的數(shù)據(jù)的做法有可能引發(fā)嚴(yán)重的寫入放大問題，這種情況下降嚴(yán)重影響固態(tài)硬盤的使用壽命。

（2）everysec 的方式，Redis 以每秒一次的頻率大隊 AOF 文件進(jìn)行同步。這樣的話既可以兼顧數(shù)據(jù)安全也可以兼顧寫入性能。

Redis 以每秒同步一次 AOF 文件的性能和不使用任何持久化特性時的性能相差無幾，使用每秒更新一次 的方式，可以保證，即使出現(xiàn)故障，丟失的數(shù)據(jù)也在一秒之內(nèi)產(chǎn)生的數(shù)據(jù)。

（3）no 的方式，Redis 將不對 AOF 文件執(zhí)行任何顯示的同步操作，而是由操作系統(tǒng)來決定應(yīng)該何時對 AOF 文件進(jìn)行同步。

這個命令一般不會對 Redis 的性能造成多大的影響，但是當(dāng)系統(tǒng)出現(xiàn)故障的時候使用這種選項的 Redis 服務(wù)器丟失不定數(shù)量的數(shù)據(jù)。

另外，當(dāng)用戶的硬盤處理寫入操作的速度不夠快的話，那么緩沖區(qū)被等待寫入硬盤的數(shù)據(jù)填滿時，Redis 的寫入操作將被阻塞，并導(dǎo)致 Redis 處理命令請求的速度變慢，因為這個原因，一般不推薦使用這個選項。

三、重寫 / 壓縮 AOF 文件

隨著數(shù)據(jù)量的增大，AOF 的文件可能會很大，這樣在每次進(jìn)行數(shù)據(jù)恢復(fù)的時候就會進(jìn)行很長的時間，為了解決日益增大的 AOF 文件，用戶可以向 Redis 發(fā)送 BGREWRITEAOF 命令，這個命令會通過移除 AOF 文件中的冗余命令來重寫 AOF 文件，是 AOF 文件的體檢變得盡可能的小。

BGREWRITEAOF 的工作原理和 BGSAVE 的原理很像：Redis 會創(chuàng)建一個子進(jìn)程，然后由子進(jìn)程負(fù)責(zé)對 AOF 文件的重寫操作。

因為 AOF 文件重寫的時候匯創(chuàng)建子進(jìn)程，所以快照持久化因為創(chuàng)建子進(jìn)程而導(dǎo)致的性能和內(nèi)存占用問題同樣會出現(xiàn)在 AOF 文件重寫的 時候。

四、觸發(fā)重寫 / 壓縮 AOF 文件條件設(shè)定

AOF 通過設(shè)置 auto-aof-rewrite-percentage 和
auto-aof-rewrite-min-size 選項來自動執(zhí)行 BGREWRITEAOF。

其具體含義，通過實例可以看出，如下配置：

auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

表示當(dāng)前 AOF 的文件體積大于 64MB，并且 AOF 文件的體積比上一次重寫之后的體積變大了至少一倍（100%）的時候，Redis 將執(zhí)行重寫 BGREWRITEAOF 命令。

如果 AOF 重寫執(zhí)行的過于頻繁的話，可以將 auto-aof-rewrite-percentage 選項的值設(shè)置為 100 以上，這種最偶發(fā)就可以讓 Redis 在 AOF 文件的體積變得更大之后才執(zhí)行重寫操作，不過，這也使得在進(jìn)行數(shù)據(jù)恢復(fù)的時候執(zhí)行的時間變得更加長一些。

驗證快照文件和 AOF 文件

無論使用哪種方式進(jìn)行持久化，我們在進(jìn)行恢復(fù)數(shù)據(jù)的時候，Redis 提供了兩個命令行程序：

redis-check-aofredis-check-dump

他們可以再系統(tǒng)發(fā)生故障的時候，檢查快照和 AOF 文件的狀態(tài)，并對有需要的情況對文件進(jìn)行修復(fù)。

如果用戶在運行 redis-check-aof 命令的時候，指定了 –fix 參數(shù)，那么程序?qū)?AOF 文件進(jìn)行修復(fù)。

程序修復(fù) AOF 文件的方法很簡單：他會掃描給定的 AOF 文件，尋找不正確或者不完整的命令，當(dāng)發(fā)現(xiàn)第一個出現(xiàn)錯誤命令的時候，程序會刪除出錯命令以及出錯命令之后的所有命令，只保留那些位于出錯命令之前的正確命令。大部分情況，被刪除的都是 AOF 文件末尾的不完整的寫命令。

到此，關(guān)于“怎么使用快照和 AOF 將 Redis 數(shù)據(jù)持久化到硬盤中”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>