Redis 持久化

Redis高可用概述

高可用是指伺服器可以正常通路的時間，衡量的标準是在多長時間内可以提供正常服務（99.9%、99.99%、99.999% 等等）。

但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(如主從分離、快速容災技術)，還需要考慮資料容量的擴充、資料安全不會丢失等。

在Redis中，實作高可用的技術主要包括持久化、複制、哨兵和叢集。

持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是資料備份，即将資料存儲在硬碟，保證資料不會因程序退出而丢失。
複制：複制是高可用Redis的基礎，哨兵和叢集都是在複制基礎上實作高可用的。複制主要實作了資料的多機備份，以及對于讀操作的負載均衡和簡單的故障恢複。缺陷：故障恢複無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。
哨兵：在複制的基礎上，哨兵實作了自動化的故障恢複。缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。
叢集：通過叢集，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實作了較為完善的高可用方案。

Redis持久化概述

持久化的功能：Redis是記憶體資料庫，資料都是存儲在記憶體中。

為了避免程序退出導緻資料的永久丢失，需要定期将Redis中的資料以某種形式(資料或指令)從記憶體儲存到硬碟；

當下次Redis重新開機時，利用持久化檔案實作資料恢複。為了進行災難備份，可以将持久化檔案拷貝到一個遠端位置。

Redis持久化分為RDB持久化和AOF持久化：前者将目前資料儲存到硬碟，後者則是将每次執行的寫指令儲存到硬碟（類似于MySQL的binlog）；

由于AOF持久化的實時性更好，即當程序意外退出時丢失的資料更少，是以AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。

RDB持久化

RDB持久化是将目前程序中的資料生成快照儲存到硬碟(是以也稱作快照持久化)，儲存的檔案字尾是rdb；當Redis重新啟動時，可以讀取快照檔案恢複資料。

手動觸發

save指令和bgsave指令都可以生成RDB檔案。

save指令會阻塞Redis伺服器程序，直到RDB檔案建立完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何指令請求。

bgsave指令會建立一個子程序，由子程序來負責建立RDB檔案，父程序(即Redis主程序)則繼續處理請求。

PS：

bgsave指令執行過程中，隻有fork子程序時會阻塞伺服器，

save指令，整個過程都會阻塞伺服器，是以save已基本被廢棄，線上環境要杜絕save的使用。

此外，在自動觸發RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化。

自動觸發

自動觸發最常見的情況是在配置檔案中通過save m n，指定當m秒内發生n次變化時，會觸發bgsave。

例如，檢視redis的預設配置檔案(Linux下為redis根目錄下的redis.conf)，可以看到如下配置資訊：

其中save 900 1的含義是：當時間到900秒時，如果redis資料發生了至少1次變化，則執行bgsave；save 300 10和save 60 10000同理。當三個save條件滿足任意一個時，都會引起bgsave的調用。

save m n的實作原理

Redis的save m n，是通過serverCron函數、dirty計數器、和 lastsave時間戳來實作的。

serverCron是Redis伺服器的周期性操作函數，預設每隔100ms執行一次；該函數對伺服器的狀态進行維護，其中一項工作就是檢查 save m n 配置的條件是否滿足，如果滿足就執行bgsave。

dirty計數器是Redis伺服器維持的一個狀态，記錄了上一次執行bgsave/save指令後，伺服器狀态進行了多少次修改(包括增删改)；而當save/bgsave執行完成後，會将dirty重新置為0。

例如，如果Redis執行了set mykey helloworld，則dirty值會+1；如果執行了sadd myset v1 v2 v3，則dirty值會+3；注意dirty記錄的是伺服器進行了多少次修改，而不是用戶端執行了多少修改資料的指令。

lastsave時間戳是Redis伺服器維持的一個狀态，記錄的是上一次成功執行save/bgsave的時間。

save m n的原理如下：每隔100ms，執行serverCron函數；在serverCron函數中，周遊save m n配置的儲存條件，隻要有一個條件滿足，就進行bgsave。

對于每一個save m n條件，隻有下面兩條同時滿足時才算滿足：

（1）目前時間-lastsave > m

（2）dirty >= n

其他自動觸發機制

除了save m n 以外，還有一些其他情況會觸發bgsave：

在主從複制場景下，如果從節點執行全量複制操作，則主節點會執行bgsave指令，并将rdb檔案發送給從節點
執行shutdown指令時，自動執行rdb持久化

執行流程

bgsave指令的執行流程，如下圖所示：

Redis父程序首先判斷：目前是否在執行save，或 bgsave/bgrewriteaof 的子程序，如果在執行則bgsave指令直接傳回。bgsave/bgrewriteaof 的子程序不能同時執行，主要是基于性能方面的考慮：兩個并發的子程序同時執行大量的磁盤寫操作，可能引起嚴重的性能問題。
父程序執行fork操作建立子程序，這個過程中父程序是阻塞的，Redis不能執行來自用戶端的任何指令
父程序fork後，bgsave指令傳回”Background saving started”資訊并不再阻塞父程序，并可以響應其他指令
子程序建立RDB檔案，根據父程序記憶體快照生成臨時快照檔案，完成後對原有檔案進行原子替換
子程序發送信号給父程序表示完成，父程序更新統計資訊

RDB檔案

存儲路徑：RDB檔案的存儲路徑既可以在啟動前配置，也可以通過指令動态設定。

配置：dir 配置指定目錄，dbfilename 指定檔案名。預設是Redis根目錄下的dump.rdb檔案。

動态設定：Redis啟動後也可以動态修改RDB存儲路徑，在磁盤損害或空間不足時非常有用；

執行指令為config set dir {newdir}和config set dbfilename {newFileName}。

RDB檔案格式：

其中各個字段的含義說明如下：

REDIS：常量，儲存着”REDIS”5個字元。
db_version：RDB檔案的版本号，注意不是Redis的版本号。
SELECTDB 0 pairs：表示一個完整的資料庫(0号資料庫)，同理SELECTDB 3 pairs表示完整的3号資料庫；隻有當資料庫中有鍵值對時，RDB檔案中才會有該資料庫的資訊(上圖所示的Redis中隻有0号和3号資料庫有鍵值對)；如果Redis中所有的資料庫都沒有鍵值對，則這一部分直接省略。其中：SELECTDB是一個常量，代表後面跟着的是資料庫号碼；0和3是資料庫号碼；pairs則存儲了具體的鍵值對資訊，包括key、value值，及其資料類型、内部編碼、過期時間、壓縮資訊等等。
EOF：常量，标志RDB檔案正文内容結束。
check_sum：前面所有内容的校驗和；Redis在載入RBD檔案時，會計算前面的校驗和并與check_sum值比較，判斷檔案是否損壞。

壓縮：Redis預設采用LZF算法對RDB檔案進行壓縮。雖然壓縮耗時，但是可以大大減小RDB檔案的體積，是以壓縮預設開啟；

可以通過指令關閉：config set rdbcompression no

RDB檔案的壓縮并不是針對整個檔案進行的，而是對資料庫中的字元串進行的，且隻有在字元串達到一定長度(20位元組)時才會進行。

啟動時加載

RDB檔案的載入工作是在伺服器啟動時自動執行的，并沒有專門的指令。

由于AOF的優先級更高，是以當AOF開啟時，Redis會優先載入AOF檔案來恢複資料；

隻有當AOF關閉時，才會在Redis伺服器啟動時檢測RDB檔案，并自動載入。

伺服器載入RDB檔案期間處于阻塞狀态，直到載入完成為止。

Redis載入RDB檔案時，會對RDB檔案進行校驗，如果檔案損壞，則日志中會列印錯誤，Redis啟動失敗。

RDB常用配置總結

RDB常用的配置項，以及預設值：

save m n：bgsave自動觸發的條件；如果沒有save m n配置，相當于自動的RDB持久化關閉，不過此時仍可以通過其他方式觸發
stop-writes-on-bgsave-error yes：當bgsave出現錯誤時，Redis是否停止執行寫指令；設定為yes，則當硬碟出現問題時，可以及時發現，避免資料的大量丢失；設定為no，則Redis無視bgsave的錯誤繼續執行寫指令，當對Redis伺服器的系統(尤其是硬碟)使用了監控時，該選項考慮設定為no
rdbcompression yes：是否開啟RDB檔案壓縮
rdbchecksum yes：是否開啟RDB檔案的校驗，在寫入檔案和讀取檔案時都起作用；關閉checksum在寫入檔案和啟動檔案時大約能帶來10%的性能提升，但是資料損壞時無法發現

AOF持久化

RDB持久化是将程序資料寫入檔案，而AOF持久化(即Append Only File持久化)，則是将Redis執行的每次寫指令記錄到單獨的日志檔案中（有點像MySQL的binlog）；當Redis重新開機時再次執行AOF檔案中的指令來恢複資料。

與RDB相比，AOF的實時性更好，是以已成為主流的持久化方案。

Redis伺服器預設開啟RDB，關閉AOF；要開啟AOF，需要在配置檔案中配置：appendonly yes

AOF 執行政策

由于需要記錄Redis的每條寫指令，是以AOF不需要觸發。

AOF的執行方式包括：

指令追加(append)：将Redis的寫指令追加到緩沖區aof_buf；
檔案寫入(write)和檔案同步(sync)：根據不同的同步政策将aof_buf中的内容同步到硬碟；
檔案重寫(rewrite)：定期重寫AOF檔案，達到壓縮的目的。

指令追加(append)

Redis先将寫指令追加到緩沖區，而不是直接寫入檔案，主要是為了避免每次有寫指令都直接寫入硬碟，導緻硬碟IO成為Redis負載的瓶頸。

指令追加的格式是Redis指令請求的協定格式，它是一種純文字格式，具有相容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點。

在AOF檔案中，除了用于指定資料庫的select指令（如select 0 為選中0号資料庫）是由Redis添加的，其他都是用戶端發送來的寫指令。

檔案寫入(write)和檔案同步(sync)

Redis提供了多種AOF緩存區的同步檔案政策，政策涉及到作業系統的write函數和fsync函數。

為了提高檔案寫入效率，在現代作業系統中，當使用者調用write函數将資料寫入檔案時，作業系統通常會将資料暫存到一個記憶體緩沖區裡，當緩沖區被填滿或超過了指定時限後，才真正将緩沖區的資料寫入到硬碟裡。

這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，記憶體緩沖區中的資料會丢失；是以系統同時提供了fsync、fdatasync等同步函數，可以強制作業系統立刻将緩沖區中的資料寫入到硬碟裡，進而確定資料的安全性。

AOF緩存區的同步檔案政策由參數appendfsync控制，各個值的含義如下：

always：指令寫入aof_buf後立即調用系統fsync操作同步到AOF檔案，fsync完成後線程傳回。這種情況下每次有寫指令都要同步到AOF檔案，硬碟IO成為性能瓶頸，Redis隻能支援大約幾百TPS寫入，嚴重降低了Redis的性能；即便是使用固态硬碟（SSD），每秒大約也隻能處理幾萬個指令，而且會大大降低SSD的壽命。
no：指令寫入aof_buf後調用系統write操作，不對AOF檔案做fsync同步；同步由作業系統負責，通常同步周期為30秒。這種情況下，檔案同步的時間不可控，且緩沖區中堆積的資料會很多，資料安全性無法保證。
everysec：指令寫入aof_buf後調用系統write操作，write完成後線程傳回；fsync同步檔案操作由專門的線程每秒調用一次。everysec是前述兩種政策的折中，是性能和資料安全性的平衡，是以是Redis的預設配置，也是我們推薦的配置。

檔案重寫(rewrite)

Redis伺服器執行的寫指令越來越多，AOF檔案也會越來越大；過大的AOF檔案不僅會影響伺服器的正常運作，也會導緻資料恢複需要的時間過長。

檔案重寫是指定期重寫AOF檔案，減小AOF檔案的體積。

AOF重寫是把Redis程序内的資料轉化為寫指令，同步到新的AOF檔案；不會對舊的AOF檔案進行任何讀取、寫入操作!

對于AOF持久化來說，檔案重寫雖然是強烈推薦的，但并不是必須的；即使沒有檔案重寫，資料也可以被持久化并在Redis啟動的時候導入；是以在一些實作中，會關閉自動的檔案重寫，然後通過定時任務在每天的某一時刻定時執行。

檔案重寫之是以能夠壓縮AOF檔案，原因在于：

過期的資料不再寫入檔案
無效的指令不再寫入檔案：如有些資料被重複設值(set mykey v1, set mykey v2)、有些資料被删除了(sadd myset v1, del myset)等等
多條指令可以合并為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合并為sadd myset v1 v2 v3。不過為了防止單條指令過大造成用戶端緩沖區溢出，對于list、set、hash、zset類型的key，并不一定隻使用一條指令；而是以某個常量為界将指令拆分為多條。這個常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義，不可更改，3.0版本中值是64。

由于重寫後AOF執行的指令減少了，檔案重寫既可以減少檔案占用的空間，也可以加快恢複速度。

檔案重寫的觸發

檔案重寫的觸發，分為手動觸發和自動觸發：

手動觸發：直接調用 bgrewriteaof 指令，該指令的執行與bgsave有些類似：都是fork子程序進行具體的工作，且都隻有在fork時阻塞。

自動觸發：根據 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 參數，以及 aof_current_size 和 aof_base_size 狀态确定觸發時機。

auto-aof-rewrite-min-size：執行AOF重寫時，檔案的最小體積，預設值為64MB。
auto-aof-rewrite-percentage：執行AOF重寫時，目前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值。

參數可以通過config get auto-aof-rewrite-min-size 指令檢視。

狀态可以通過info persistence檢視。

隻有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個參數同時滿足時，才會自動觸發AOF重寫，即bgrewriteaof操作。

檔案重寫的流程

檔案重寫流程如下圖所示：

重寫由父程序fork子程序進行，重寫期間Redis執行的寫指令，需要追加到新的AOF檔案中，為此Redis引入了aof_rewrite_buf緩存。

檔案重寫的流程如下：

Redis父程序首先判斷目前是否存在正在執行 bgsave/bgrewriteaof的子程序，如果存在則bgrewriteaof指令直接傳回，如果存在bgsave指令則等bgsave執行完成後再執行。
父程序執行fork操作建立子程序，這個過程中父程序是阻塞的。
父程序fork後，bgrewriteaof指令傳回”Background append only file rewrite started”資訊并不再阻塞父程序，并可以響應其他指令。Redis的所有寫指令依然寫入AOF緩沖區，并根據appendfsync政策同步到硬碟，保證原有AOF機制的正确。
由于fork操作使用寫時複制技術，子程序隻能共享fork操作時的記憶體資料。由于父程序依然在響應指令，是以Redis使用AOF重寫緩沖區(圖中的aof_rewrite_buf)儲存這部分資料，防止新AOF檔案生成期間丢失這部分資料。也就是說，bgrewriteaof執行期間，Redis的寫指令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區。
子程序根據記憶體快照，按照指令合并規則寫入到新的AOF檔案。
子程序寫完新的AOF檔案後，向父程序發信号，父程序更新統計資訊，具體可以通過info persistence檢視。
父程序把AOF重寫緩沖區的資料寫入到新的AOF檔案，這樣就保證了新AOF檔案所儲存的資料庫狀态和伺服器目前狀态一緻。
使用新的AOF檔案替換老檔案，完成AOF重寫。

當AOF開啟時，Redis啟動時會優先載入AOF檔案來恢複資料；隻有當AOF關閉時，才會載入RDB檔案恢複資料。

當AOF開啟，但AOF檔案不存在時，即使RDB檔案存在也不會加載。

檔案校驗：

Redis載入AOF檔案時，會對AOF檔案進行校驗，如果檔案損壞，則日志中會列印錯誤，Redis啟動失敗。

但如果是AOF檔案結尾不完整(機器突然當機等容易導緻檔案尾部不完整)，且aof-load-truncated參數開啟，則日志中會輸出警告，Redis忽略掉AOF檔案的尾部，啟動成功。aof-load-truncated參數預設是開啟的。

僞用戶端：

因為Redis的指令隻能在用戶端上下文中執行，而載入AOF檔案時指令是直接從檔案中讀取的，并不是由用戶端發送；

是以Redis伺服器在載入AOF檔案之前，會建立一個沒有網絡連接配接的用戶端，之後用它來執行AOF檔案中的指令，指令執行的效果與帶網絡連接配接的用戶端完全一樣。

AOF常用配置總結

下面是AOF常用的配置項，以及預設值：

appendonly no：是否開啟AOF
appendfsync everysec：fsync持久化政策
no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync；如果開啟該選項，可以減輕檔案重寫時CPU和硬碟的負載（尤其是硬碟），但是可能會丢失AOF重寫期間的資料；需要在負載和安全性之間進行平衡
auto-aof-rewrite-percentage 100：檔案重寫觸發條件之一
auto-aof-rewrite-min-size 64mb：檔案重寫觸發送出之一
aof-load-truncated yes：如果AOF檔案結尾損壞，Redis啟動時是否仍載入AOF檔案

方案選擇與常見問題

RDB和AOF的優缺點

優點：RDB檔案緊湊，體積小，網絡傳輸快，适合全量複制；恢複速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對性能的影響相對較小。

缺點：RDB檔案的緻命缺點在于其資料快照的持久化方式決定了必然做不到實時持久化，而在資料越來越重要的今天，資料丢失很多時候是無法接受的，是以AOF持久化成為主流。此外，RDB檔案需要滿足特定格式，相容性差（如老版本的Redis不相容新版本的RDB檔案）。

與RDB持久化相對應，AOF的優點在于支援秒級持久化、相容性好，缺點是檔案大、恢複速度慢、對性能影響大。

持久化政策選擇

無論是RDB還是AOF，持久化的開啟都是要付出性能方面代價的：

對于RDB持久化，一方面是bgsave在進行fork操作時Redis主程序會阻塞，另一方面，子程序向硬碟寫資料也會帶來IO壓力；

對于AOF持久化，向硬碟寫資料的頻率大大提高(everysec政策下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題，此外，AOF檔案的重寫與RDB的bgsave類似，會有fork時的阻塞和子程序的IO壓力問題。相對來說，由于AOF向硬碟中寫資料的頻率更高，是以對Redis主程序性能的影響會更大。

在實際生産環境中，根據資料量、應用對資料的安全要求、預算限制等不同情況，會有各種各樣的持久化政策；如完全不使用任何持久化、使用RDB或AOF的一種，或同時開啟RDB和AOF持久化等。

此外，持久化的選擇必須與Redis的主從政策一起考慮，因為主從複制與持久化同樣具有資料備份的功能，而且主機master和從機slave可以獨立的選擇持久化方案。

下面分場景來讨論持久化政策的選擇：

如果Redis中的資料完全丢棄也沒有關系（如Redis完全用作DB層資料的cache），那麼無論是單機，還是主從架構，都可以不進行任何持久化。
在單機環境下（對于個人開發者，這種情況可能比較常見），如果可以接受十幾分鐘或更多的資料丢失，選擇RDB對Redis的性能更加有利；如果隻能接受秒級别的資料丢失，應該選擇AOF。
在多數情況下，我們都會配置主從環境，slave的存在既可以實作資料的熱備，也可以進行讀寫分離分擔Redis讀請求，以及在master宕掉後繼續提供服務
- master：完全關閉持久化（包括RDB和AOF），這樣可以讓master的性能達到最好
- slave：關閉RDB，開啟AOF（如果對資料安全要求不高，開啟RDB關閉AOF也可以），并定時對持久化檔案進行備份（如備份到其他檔案夾，并标記好備份的時間）；然後關閉AOF的自動重寫，然後添加定時任務，在每天Redis閑時（如淩晨12點）調用bgrewriteaof。

異地災備：上述讨論的幾種持久化政策，針對的都是一般的系統故障，如程序異常退出、當機、斷電等，這些故障不會損壞硬碟。但是對于一些可能導緻硬碟損壞的災難情況，如火災地震，就需要進行異地災備。例如對于單機的情形，可以定時将RDB檔案或重寫後的AOF檔案，通過scp拷貝到遠端機器，如阿裡雲、AWS等；對于主從的情形，可以定時在master上執行bgsave，然後将RDB檔案拷貝到遠端機器，或者在slave上執行bgrewriteaof重寫AOF檔案後，将AOF檔案拷貝到遠端機器上。一般來說，由于RDB檔案檔案小、恢複快，是以災難恢複常用RDB檔案；異地備份的頻率根據資料安全性的需要及其他條件來确定，但最好不要低于一天一次。

fork阻塞：CPU的阻塞

在Redis的實踐中，衆多因素限制了Redis單機的記憶體不能過大，例如：

當面對請求的暴增，需要從庫擴容時，Redis記憶體過大會導緻擴容時間太長；
當主機當機時，切換主機後需要挂載從庫，Redis記憶體過大導緻挂載速度過慢；
以及持久化過程中的fork操作，下面詳細說明。

父程序通過fork操作可以建立子程序；子程序建立後，父子程序共享代碼段，不共享程序的資料空間，但是子程序會獲得父程序的資料空間的副本。

在作業系統fork的實際實作中，基本都采用了寫時複制技術，即在父/子程序試圖修改資料空間之前，父子程序實際上共享資料空間；但是當父/子程序的任何一個試圖修改資料空間時，作業系統會為修改的那一部分(記憶體的一頁)制作一個副本。

雖然fork時，子程序不會複制父程序的資料空間，但是會複制記憶體頁表（頁表相當于記憶體的索引、目錄）；父程序的資料空間越大，記憶體頁表越大，fork時複制耗時也會越多。

在Redis中，無論是RDB持久化的bgsave，還是AOF重寫的bgrewriteaof，都需要fork出子程序來進行操作。如果Redis記憶體過大，會導緻fork操作時複制記憶體頁表耗時過多；

Redis主程序在進行fork時，是完全阻塞的，也就意味着無法響應用戶端的請求，會造成請求延遲過大。

對于不同的硬體、不同的作業系統，fork操作的耗時會有所差别，一般來說，如果Redis單機記憶體達到了10GB，fork時耗時可能會達到百毫秒級别（如果使用Xen虛拟機，這個耗時可能達到秒級别）。

是以，一般來說Redis單機記憶體一般要限制在10GB以内；不過這個資料并不是絕對的，可以通過觀察線上環境fork的耗時來進行調整。

觀察的方法如下：執行指令info stats，檢視latest_fork_usec的值，機關為微秒。

AOF追加阻塞：硬碟的阻塞

在AOF中，如果AOF緩沖區的檔案同步政策為everysec。

在主線程中，指令寫入aof_buf後調用系統write操作，write完成後主線程傳回；fsync同步檔案操作由專門的檔案同步線程每秒調用一次。

如果硬碟負載過高，那麼fsync操作可能會超過1s；

如果Redis主線程持續高速向aof_buf寫入指令，硬碟的負載可能會越來越大，IO資源消耗更快；

如果此時Redis程序異常退出，丢失的資料也會越來越多，可能遠超過1s。

為此Redis的處理政策是這樣的：主線程每次進行AOF會對比上次fsync成功的時間；如果距上次不到2s，主線程直接傳回；如果超過2s，則主線程阻塞直到fsync同步完成。

是以，如果系統硬碟負載過大導緻fsync速度太慢，會導緻Redis主線程的阻塞；此外，使用everysec配置，AOF最多可能丢失2s的資料，而不是1s。

AOF追加阻塞問題定位的方法：

（1）監控info Persistence中的aof_delayed_fsync：當AOF追加阻塞發生時（即主線程等待fsync而阻塞），該名額累加。

（2）AOF阻塞時的Redis日志：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

（3）如果AOF追加阻塞頻繁發生，說明系統的硬碟負載太大；可以考慮更換IO速度更快的硬碟，或者通過IO監控分析工具對系統的IO負載進行分析，如iostat（系統級io）、iotop（io版的top）、pidstat等。

info指令與持久化

info persistence 其中比較重要的包括：

rdb_last_bgsave_status:上次bgsave 執行結果，可以用于發現bgsave錯誤
rdb_last_bgsave_time_sec:上次bgsave執行時間（機關是s），可以用于發現bgsave是否耗時過長
aof_enabled:AOF是否開啟
aof_last_rewrite_time_sec: 上次檔案重寫執行時間（機關是s），可以用于發現檔案重寫是否耗時過長
aof_last_bgrewrite_status: 上次bgrewrite執行結果，可以用于發現bgrewrite錯誤
aof_buffer_length和aof_rewrite_buffer_length:aof緩存區大小和aof重寫緩沖區大小
aof_delayed_fsync:AOF追加阻塞情況的統計

info stats 其中與持久化關系較大的是：latest_fork_usec，代表上次fork耗時。

作者：程式設計迷思

出處：http://www.cnblogs.com/kismetv/p/8654978.html