在數據庫(如mysql)和緩存(如redis)的發展中，都會相互借鑒對方的長處來彌補自身的不足。比如mysql作為持久化數據庫，為了提高數據的訪問速度，會使用緩存技術，當一條sql查詢完成后，mysql會使用sql生成一個key，并將這個sql查詢的結果緩存到這個key上，如果運行相同的sql，服務器直接從緩存中去獲取結果，就不需要再去解析、優化、執行sql了。同時，redis作為緩存，為了解決宕機帶了的數據丟失問題，也增加了持久化機制。

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

今天我們就聊一聊redis的持久化問題。本期也是面試高頻問題，同時也是實際生產必須考慮的問題。

一、RDB(Redis DataBase)

默認情況下，只開啟RDB。RDB是二進制文件。

原理

RDB方式也叫快照方式，這種方式會在一定的觸發時機下，將當前redis的內存快照保存到磁盤上的dump.rdb文件中。這個過程中，主要執行一個命令bgsave。

bgsave過程

1.在一定的條件下觸發bgsave執行2.Redis父進程判斷當前是否存在正在執行的子進程，如RDB/AOF子進程，如果存在bgsave命令直接返回。3.父進程執行fork操作創建子進程，fork操作過程中父進程會阻塞，不能響應其他客戶端請求。通過info stats命令查看latest_fork_usec選項，可以獲取最近一個fork操作的耗時，單位為微秒。Fork的作用是復制一個與當前進程一樣的進程。新進程的所有數據(變量、環境變量、程序計數器等)數值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程。4.父進程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父進程，可以繼續響應其他客戶端命令。5.子進程創建RDB文件dump.rdb，根據父進程內存生成臨時快RDB文件。6.使用臨時RDB文件對原有RDB文件的原子替換。執行lastsave命令可以獲取最后一次生成RDB的時間，對應info統計的rdb_last_save_time選項7.子進程退出。

配置

################################ SNAPSHOTTING #################################900s內，如果至少有一個1key進行了修改，就進行持久化操作save 900 1#300s內，如果至少有一個10key進行了修改，就進行持久化操作save 300 10#60s內，如果至少有一個10000key進行了修改，就進行持久化操作save 60 10000#持久化如果出錯，是否還需要繼續工作stop-writes-on-bgsave-error yes#是否壓縮rdb文件，需要消耗一些cpu資源rdbcompression yes#保存rdb文件的時候,進行錯誤的檢查校驗rdbchecksum yes#持久化的文件名字dbfilename dump.rdb#rdb文件保存的目錄dir ./

觸發機制

觸發RDB持久化過程分為手動觸發和自動觸發。

手動觸發

通過redis-cli登錄redis后，可以使用save和bgsave兩個命令觸發RDB持久化。

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

顯然bgsave命令是針對save阻塞問題做的優化。因此Redis內部所有的涉及RDB的操作都采用bgsave的方式，而save命令已經廢棄。

自動觸發

除了執行命令手動觸發之外，Redis內部還存在自動觸發RDB的持久化機制。

?滿足上面配置文件中save m n的觸發條件時，redis會自動執行bgsave。?slave全量復制master時，會發信息給master，這是master會執行bgsave，執行完成之后會將rdb文件發送給slave。?執行shutdown和flushall命令時，redis會自動執行bgsave。

可以在redis-cli的命令行執行config set save " "關閉RDB的持久化機制。

數據恢復

rdb文件會自動恢復。在redis客戶端命令行通過config get dir獲取 redis 的安裝目錄，將備份文件 (dump.rdb) 移動到 安裝目錄并啟動服務即可，redis就會自動加載文件數據至內存了。

Redis啟動后會讀取RDB快照文件，將數據從硬盤載入到內存。根據數據量大小與結構和服務器性能不同，這個時間也不同。RDB本身是二進制文件，恢復非常快。通常將一個記錄一千萬個字符串類型鍵、大小為1GB的快照文件載入到內存中需要花費20～30秒鐘。

127.0.0.1:6379> config get dir #獲取redis的目錄1) "dir"2) "/usr/local/bin" # 將dump.rdb文件放在這個目錄下，重新啟動redis，就可以自動將數據恢復

優缺點

優點

代表Redis在某個時間點上的數據快照。非常適用于備份，全量復制等場景。比如每6小時執行bgsave備份，并把RDB文件拷貝到遠程機器或者文件系統中(如hdfs)，用于災難恢復(對數據完整性和一致性要求不高)

RDB是二進制保存，Redis加載RDB恢復數據遠遠快于AOF的方式(適合大規模的數據恢復)

缺點

RDB方式沒辦法做到實時持久化/秒級持久化。因為bgsave每次運行都要執行fork操作創建子進程，屬于重量級操作(內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮)，頻繁執行成本過高(影響性能)

RDB文件使用特定二進制格式保存，Redis版本演進過程中有多個格式的RDB版本，存在老版本Redis服務無法兼容新版RDB格式的問題(版本不兼容)

在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改。

二、AOF(Append Only File)

默認情況下，aof是關閉的。AOF命令寫入的內容直接是文本協議格式，可以通過vim查看文件內容。

原理

以獨立日志的方式記錄每次寫命令，重啟時再重新執行AOF文件中的命令達到恢復數據的目的。AOF的主要作用是解決了數據持久化的實時性，目前已經是Redis持久化的主流方式。掌握AOF持久化機制，對兼顧數據安全性和性能非常有幫助。通俗一點的理解就是以日志的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。

aof的持久化有三步：命令寫入(append)、文件同步(sync)、文件重寫(rewrite)。

1.所有的寫入命令會追加到aof_buf(緩沖區)中。2.AOF緩沖區根據對應的策略向硬盤做同步操作。3.隨著AOF文件越來越大，需要定期對AOF文件進行重寫，達到壓縮的目的。

Rewrite原理 : AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)。遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似。

配置

############################## APPEND ONLY MODE ################################ 默認不開啟aop持久化機制，因為RDB對于一般的業務已經夠用了appendonly no# aof持久化文件名稱appendfilename "appendonly.aof"# 不執行sync, 完全依賴操作系統的刷寫，一般30秒一次。性能最好，但是持久化沒有保障，不推薦# appendfsync no# 每次有寫命令執行，就會執行一次sync，將命令追加到aof日志文件。保證完全持久化，不會丟數據，性能也是最差的，不推薦# appendfsync always# 每秒鐘執行一次sync，將命令追加到aof日志文件。在性能和持久化之間做了折中，推薦。也是默認配置appendfsync everysec# 默認不會對aof文件使用BGREWRITEAOF命令進行重寫(重寫會合并命令，減小aof文件占用的空間)no-appendfsync-on-rewrite no# 當aof文件占用的空間超過上一次記錄的100%時，并且aof文件每增加64M，就會執行重寫(兩個條件同時滿足)auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb# 加載aof文件時，如果文件本身有問題(如文件結尾)，是否繼續加載。yes:繼續加載，no:加載出現錯誤，停止加載，需要修復aof文件后才能加載，這是不能重啟redisaof-load-truncated yes

這里需要注意的是觸發sync的配置和rewrite的配置。

觸發機制

AOF的appendfsync觸發機制是上面配置的三個參數決定的：no、always、everysec。可以根據對性能和持久化的實時性要求，具體配置。如果不知道哪種合適，就使用默認的everysec，可能會有1s的數據丟失。

aof文件的重寫過程的觸發，由上面配置的rewrite參數決定。可以手動觸發和自動觸發。

手動觸發rewrite

通過redis-cli登錄redis后，可以使用bgrewriteaof命令觸發aof的重寫機制。

自動動觸發rewrite

根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數確定自動觸發時機，當兩個條件同時滿足時，就會觸發重寫。

數據恢復

redis啟動時，首先判斷aof功能是否開啟，如果開啟并且存在aof持久化文件，則只會使用aof文件進行數據恢復，而不會使用rdb文件進行數據恢復。

使用aof文件恢復時，AOF文件可能存在結尾不完整的情況，比如機器突然掉電導致AOF尾部文件命令寫入不全。Redis為我們提供了aof-load-truncated配置來兼容這種情況，默認開啟。加載AOF時，當遇到此問題時會忽略并繼續啟動。

如果關閉aof-load-truncated配置，當aof文件不完整時，則redis會啟動失敗，這時使用客戶端連接也是失敗的：

[root@redis ~]# redis-cli -p 6379Could not connect to Redis at 127.0.0.1:6379: Connection refusednot connected> exit[root@redis ~]#

對于錯誤格式的AOF文件，可以先進行備份，然后采用redis安裝目錄下的redis-check-aof命令修復aof文件，修復后使用linux的命令diff -u對比數據的差異，找出丟失的數據，有些可以人工修改補全。

[root@redis ~]# redis-check-aof --fix appendonly.aof0x a4: Expected \n\r, got:6461AOF analyzed: size=185, ok_up_to=139, diff=46This will shrink the AOF form 185 bytes, with 46 bytes, to 139 bytesContinue? [y/N]: y # 輸入y，同意修改Successfully truncated AOF[root@redis ~]#

優缺點

優點

1.每一次修改都同步，文件完整性更高。2.可以根據具體業務，選擇同步的參數，可以兼顧性能和同步的實時性。每一秒同步一次，可只會丟失1秒鐘的數據。

缺點

1.AOF文件遠大于RDB文件，數據恢復速度比rdb慢。

三、總結

1、RDB持久化方式能夠在指定的時間間隔內對數據進行快照存儲，默認開啟。

2、AOF持久化方式記錄每次對服務器寫操作，當服務器重啟的時候會重新執行這些命令來恢復原始的數據。AOF持久化會追加保存每次寫的操作到文件末尾， Redis還能對AOF文件進行后臺重寫(rewiter)，使得AOF文件的體積不至于過大。默認不開啟。

3、如果每次重啟機器，都有單獨的服務將mysql中的數據加載到redis中，也可以不使用任何持久化。

4、同時開啟兩種持久化方式

?在這種情況下，當 redis重啟的時候，會優先載入aof文件恢復原始數據。因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集完整。?RDB文件的完整性沒有AOF高，同時使用兩者時，服務器重啟也只會使用AOF文件，那要不要只使用AOF呢？建議不要，因為RDB更適合用于備份數據庫(AOF在不斷變化不好備份)，是二進制存儲恢復快，而且不會有AOF可能潛在的Bug，留著作為一個萬一的手段。

5、性能建議

?因為RDB文件只用作數據備份，建議只在Slave上持久化RDB文件,而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。?如果開啟aof，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單，只load自己的AOF文件就可以了，代價一是帶來了持續的IO；二是 AOF rewrite的最后將 rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。應該盡量減少 AOF rewrite的頻率，AOF重寫的基礎大小默認值64M(auto-aof-rewrite-min-size 64mb)太小了，可以設到5G以上；默認超過原大小100%大小重寫可以改到適當的數值。?如果不開啟aof，僅靠 Master-Slave Replication實現高可用性也可以，能省掉一大筆IO，也減少了rewrite時帶來的系統波動。代價是如果 Master/Slave同時宕機，會丟失十幾分鐘的數據，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。

完成，收工！

【傳播知識，共享價值】，感謝小伙伴們的關注和支持，我是【諸葛小猿】，一個彷徨中奮斗的互聯網民工！！！

總結

以上是生活随笔為你收集整理的重启redis命令_redis系列之——数据持久化（RDB和AOF）的全部內容，希望文章能夠幫你解決所遇到的問題。

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