前言

Redis支持RDB和AOF兩種持久化機制， 持久化功能有效地避免因進程退出造成的數據丟失問題， 當下次重啟時利用之前持久化的文件即可實現數據恢復。

RDB介紹

按指定時間間隔把數據生成快照保存到硬盤的過程,觸發RDB持久化過程分為手動觸發和自動觸發。

自動觸發

RDB的配置參數在配置文件redis.conf

#時間策略save 900 1save 300 10save 60 10000

這里說一下save的時間策略配置默認是三個，拿其中一個做說明,其他同理：

• save 900 1 表示900s內至少有一個鍵更改，就會觸發產生一次快照。

如果要關閉RDB快照生成可以直接在時間策略最尾部加上

save ""

為什么要設置這么多條規則,因為考慮到每個時段的讀寫請求不一定是均衡的,為了平衡性能和數據安全,我們可以自由定制什么情況下觸發備份。所以這里就是根據自身Redis寫入情況來進行合理配置。

#文件名稱dbfilename dump.rdb#文件保存路徑dir ./#壓縮：默認采用LZF算法對生成的RDB文件做壓縮處理,壓縮會消耗CPU,但可大幅降低文件體積rdbcompression yes#默認情況下，如果Redis在后臺生成快照的時候失敗，那么就會停止接收數據，目的是讓用戶能知道數據沒有持久化成功。但是如果你有其他的方式可以監控到Redis及其持久化的狀態，那么可以把這個功能禁止掉。stop-writes-on-bgsave-error yes#導入時是否校驗rdbchecksum yes

默認Redis會把快照文件存儲為當前目錄下一個名為dump.rdb的文件

手動觸發save和bgsave

• save命令：阻塞當前Redis服務器，直到RDB過程完成為止,對于內存比較大的實例會造成長時間阻塞,線上環境不建議使用。
• bgsave命令：Redis進程執行fork操作創建子進程， RDB持久化過程由子進程負責， 完成后自動結束。 阻塞只發生在fork階段， 一般時間很短。

顯然bgsave命令是對save阻塞問題進行的優化,我們要重點看看bgsave的工作流程。

bgsave工作流程

執行bgsave命令，Redis父進程判斷當前是否存在正在執行的子進程,如RDB/AOF子進程，如果存在bgsave命令則直接返回。

父進程執行fork操作創建子進程，fork操作過程中父進程會阻塞，通過info stats命令查看latestforkusec選項，可以獲取最近一個fork操作的耗時，單位為微秒。

父進程fork完成后， bgsave命令返回“Background saving started”信息并不再阻塞父進程， 可以繼續響應其他命令。

子進程創建RDB文件， 根據父進程內存生成臨時快照文件， 完成后對原有文件進行原子替換。 執行lastsave命令可以獲取最后一次生成RDB的時間， 對應info統計的rdblastsave_time選項。

進程發送信號給父進程表示完成， 父進程更新統計信息， 具體見info Persistence下的rdb_*相關選項。

除了執行命令手動觸發之外，Redis內部還存在自動觸發RDB的持久化 機制，例如以下場景：

• 使用save相關配置，如“save m n”。表示m秒內數據集存在n次修改 時，自動觸發bgsave。
• 如果從節點執行全量復制操作，主節點自動執行bgsave生成RDB文件并發送給從節點。
• 執行debug reload命令重新加載Redis時，也會自動觸發save操作。
• 默認情況下執行shutdown命令時，如果沒有開啟AOF持久化功能則 自動執行bgsave。

優點

• RDB是一個緊湊壓縮的二進制文件,代表Redis在某個時間點上的數據快照。非常適用于備份，全量復制等場景。比如6小時執行bgsave備份。
• 基于上面所描述的特性，RDB很適合用于災備。單文件很方便就能傳輸到遠程的服務器上。
• RDB的性能很好，需要進行持久化時，主進程會fork一個子進程出來，然后把持久化的工作交給子進程，自己不會有相關的I/O操作。
• Redis加載RDB恢復數據遠遠快于AOF的方式。

缺點

• RDB容易造成數據的丟失。假設每5分鐘保存一次快照，如果Redis因為某些原因不能正常工作，那么從上次產生快照到Redis出現問題這段時間的數據就會丟失了。
• ·RDB方式數據沒辦法做到實時持久化/秒級持久化。因為bgsave每次運 行都要執行fork操作創建子進程，屬于重量級操作，頻繁執行成本過高。
• ·RDB文件使用特定二進制格式保存，Redis版本演進過程中有多個格式 的RDB版本，存在老版本Redis服務無法兼容新版RDB格式的問題。

針對RDB不適合實時持久化的問題,Redis提供了AOF持久化方式來解決。

AOF介紹

以獨立日志的方式記錄每次寫命令.重啟時再重新執行AOF文件中的命令達到恢復數據的目的。AOF的主要作用是解決了數據持久化的實時性， 目前已經是Redis持久化的主流方式。

AOF文件配置

詳看配置文件redis.conf

#是否開啟AOF(yes or no)appendonly yes #文件名稱appendfilename "appendonly.aof"#文件保存路徑,與RDB共用dir ./

默認Redis會把文件存儲為當前目錄下一個名為appendonly.aof的文件

#同步頻率# appendfsync always appendfsync everysec# appendfsync no

特地把AOF的同步頻率的配置拿出來講,redis調用fsync的頻率分三個：

• appendfsync always 每次將新命令附加到AOF，非常慢,非常安全。(這里安全指的就是進程掛掉時候數據丟失的安全性)
• 每秒fsync一次。速度快(再2.4版本中與快照方式的速度差不多),安全性不錯(最多丟失1秒的數據)
• 從不fsync,交給系統處理。速度非常快,但安全性一般,通常,Linux使用此配置30秒刷新一次數據。

默認采取的策略是fsync每秒執行一次,即快速又安全。

工作流程

AOF的工作流程操作： 命令寫入(append)、文件同步(sync) 、 文件重寫(rewrite)、重啟加載 (load)

流程如下：

所有的寫入命令會追加到aof_buf(緩沖區)中。

AOF緩存區根據對應的策略向磁盤做同步操作。

隨著AOF文件越來越大，需要定期對AOF文件進行重寫，達到壓縮的目的。

當Redis服務器重啟時，可以加載AOF文件進行數據恢復。

優點

• 比RDB可靠。你可以制定不同的fsync策略：不進行fsync、每秒fsync一次和每次查詢進行fsync。默認是每秒fsync一次。這意味著你最多丟失一秒鐘的數據。
• AOF日志文件是一個純追加的文件。就算是遇到突然停電的情況，也不會出現日志的定位或者損壞問題。甚至如果因為某些原因(例如磁盤滿了)命令只寫了一半到日志文件里，我們也可以用redis-check-aof這個工具很簡單的進行修復。
• 當AOF文件太大時，Redis會自動在后臺進行重寫。重寫很安全，因為重寫是在一個新的文件上進行，同時Redis會繼續往舊的文件追加數據。新文件上會寫入能重建當前數據集的最小操作命令的集合。當新文件重寫完，Redis會把新舊文件進行切換，然后開始把數據寫到新文件上。
• AOF把操作命令以簡單易懂的格式一條接一條的保存在文件里，很容易導出來用于恢復數據。例如我們不小心用FLUSHALL命令把所有數據刷掉了，只要文件沒有被重寫，我們可以把服務停掉，把最后那條命令刪掉，然后重啟服務，這樣就能把被刷掉的數據恢復回來。

缺點

• 在相同的數據集下，AOF文件的大小一般會比RDB文件大。
• 在某些fsync策略下，AOF的速度會比RDB慢。通常fsync設置為每秒一次就能獲得比較高的性能，而在禁止fsync的情況下速度可以達到RDB的水平。
• 在過去曾經發現一些很罕見的BUG導致使用AOF重建的數據跟原數據不一致的問題。

重寫機制

隨著命令不斷寫入AOF， 文件會越來越大， 為了解決這個問題， Redis引入AOF重寫機制壓縮文件體積。 重寫后的AOF文件會變小，原因如下：

• 進程內已經超時的數據不再寫入文件。
• 舊的AOF文件含有無效命令， 如del key1、 hdel key2、 srem keys、 set a111、 set a222等。 重寫使用進程內數據直接生成， 這樣新的AOF文件只保留最終數據的寫入命令。
• 多條寫命令可以合并為一個， 如： lpush list a、 lpush list b、 lpush list c可以轉化為： lpush list a b c。 為了防止單條命令過大造成客戶端緩沖區溢出， 對于list、 set、 hash、 zset等類型操作， 以64個元素為界拆分為多條。

AOF重寫降低了文件占用空間， 除此之外， 另一個目的是： 更小的AOF文件可以更快地被Redis加載。

AOF重寫過程可以手動觸發和自動觸發： 自動觸發

auto-aof-rewrite-min-size 64mb

表示運行AOF重寫時文件最小體積， 默認為64MB。

auto-aof-rewrite-percentage 100

代表當前AOF文件空間( aofcurrentsize) 和上一次重寫后AOF文件空間( aofbasesize) 的比 值。

自動觸發時機=aofcurrentsize>auto-aof-rewrite-minsize&&( aofcurrentsize-aofbasesize) /aofbasesize>=auto-aof-rewritepercentage

表示觸發重寫的條件是文件大小最小為64mb,并且aof文件大小超過上一次重寫文件的百分之百時會觸發重寫。

手動觸發 手動觸發直接調用bgrewriteaof命令。

bgrewriteaof工作流程

執行AOF重寫請求。如果當前進程正在執行AOF重寫， 請求不執行并返回。如果當前進程正在執行bgsave操作， 重寫命令延遲到bgsave完成之后再執行。

父進程執行fork創建子進程， 開銷等同于bgsave過程。

主進程fork操作完成后， 繼續響應其他命令。 所有修改命令依然寫入AOF緩沖區并根據appendfsync策略同步到硬盤， 保證原有AOF機制正確性。

由于fork操作運用寫時復制技術， 子進程只能共享fork操作時的內存數據。 由于父進程依然響應命令， Redis使用“AOF重寫緩沖區”保存這部分新數據， 防止新AOF文件生成期間丟失這部分數據。

子進程根據內存快照， 按照命令合并規則寫入到新的AOF文件。 每次批量寫入硬盤數據量由配置aof-rewrite-incremental-fsync控制， 默認為32MB， 防止單次刷盤數據過多造成硬盤阻塞。

新AOF文件寫入完成后， 子進程發送信號給父進程， 父進程更新統計信息， 具體見info persistence下的aof_*相關統計。

父進程把AOF重寫緩沖區的數據寫入到新的AOF文件。

使用新AOF文件替換老文件， 完成AOF重寫。

重啟加載

AOF和RDB文件都可以用于服務器重啟時的數據恢復。 加載流程

AOF持久化開啟且存在AOF文件時， 優先加載AOF文件。

AOF關閉或者AOF文件不存在時， 加載RDB文件。

加載AOF/RDB文件成功后， Redis啟動成功。

AOF/RDB文件存在錯誤時， Redis啟動失敗并打印錯誤信息。

總結

以上是生活随笔為你收集整理的redis重启命令_请收下这份redis持久化详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。