序言

  在上一篇部落格中，部落格介紹了redis的資料型別使用場景和redis分散式鎖的正確姿勢。我們知道一旦Redis重啟，存在redis裡面的資料就會全部丟失。所以這篇部落格中向大家介紹Redis的磁碟持久化。

REDIS持久化

　　以每隔一段時間對redis進行快照的方式實現持久化

RDB持久化

　　優點：1、對redis效能影響小。

　　　　　2、資料集比較大的時候，恢復速度比AOF快。

　　　　   3、RDB是一個非常緊湊的單一檔案，很方便傳到第三方資料中心（亞馬遜S3），以便日後的災難恢復。

　　缺點：1、因為RDB的快照持久化方式，所以一旦出現宕機，你可能丟失幾分鐘的資料。

　　　　　2、RDB需要fork一個子程序來儲存資料集到磁碟上，所以當資料集比較大的時候，就會造成redis在毫秒級內對客戶端沒反應。

　　配置檔案：在redis.conf檔案中，有這樣一段話。

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 
 
900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty 
 
string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

說明在三種策略下，RDB會執行快照來將資料儲存在磁碟上。例如 save 60 10000 意思是，"60秒內至少有1000個鍵被改動"，這自動儲存一次資料集。

notice：當redis剛啟動，這時你使用redis-cli向redis中存入一條資料，會發現並沒有生成dump.rdb。這是因為這時候還沒有滿組以上三種策略，所以不會執行bgsave命令，這時要麼你等900秒，要麼你進入redis-cli，主動執行bgsave命令。

這樣就會生成dump.rdb。

　　工作方式：當需要資料持久化的時候，會執行一下操作

　　　　1、Redis呼叫forks.同時擁有父程序和子程序。(這個過程是阻塞的)

　　　　2、子程序將資料集寫入一個臨時的rdb檔案中。

　　　　3、Redis用新的rdb檔案替換舊的rdb檔案，並刪除舊的rdb檔案。

AOF持久化

　　以向AOF檔案中追加redis寫操作方式實現持久化

　　優點：1、AOF有三種策略：無fsync(完全依賴系統,效能很接近RDB)、每秒fsync、寫時fsync(資料完全同步，但效能比較差)。預設使用每秒fsync，這種策略，即使redis宕機，最多也只會丟失一秒中的資料，兼顧效能和資料實時性。

　　　　   2、當向AOF檔案寫入命令時，由於某些問題(磁碟已滿或寫時宕機等)造成未寫入完整的命令，可以使用redis-check-aof命令修復這些問題。

　　　　　3、當AOF檔案過大時，會自動重寫AOF檔案。(例如我們只能了一百次incr count,就會在AOF檔案中追加100次這個命令，那麼重寫後，就只會有一條類似set count 100的命令)。

　　　　　4、AOF 檔案有序地儲存了對redis執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式儲存，非常的容易讀懂。因此當我們執行一些誤操作(FLUSHALL)的時候，也可以通過修改AOF檔案來修復資料。

　　缺點：1、相同的資料集情況下，體積會比rdb大。

　　　　　2、除非使用無fsync，不然AOF的效能都慢於RDB。

　　配置檔案：同樣去看redis.conf檔案中的配置註釋。主要配置如下

appendonly yes                      是否開啟AOF持久化
appendfilename "appendonly.aof"     AOF檔名

# appendfsync always　　　　　　　　　 每次寫入時都追加的AOF檔案中
appendfsync everysec　　　　　　　　　 每秒同步一次AOF檔案
# appendfsync no　　　　　　　　　　　　不同步AOF檔案，完全依賴作業系統

 下面還有一些其他引數配置，詳細的可以去官網下載一份對應版本的redis.conf檔案。

　　工作原理：AOF重寫和RDB建立快照一樣，都巧妙的利用了redis寫時複製機制：

　　　　1、redis執行fork()，同時擁有父程序和子程序。

　　　　2、子程序將新AOF命令寫入到臨時檔案中。

　　　　3、所有新執行的寫入命令，redis一邊將其放入記憶體快取中，一邊寫入現有的AOF檔案中，這樣即使AOF重寫中redis發生宕機，現有AOF檔案也是安全的。

　　　　4、當子程序完成AOF重寫時，會給父程序傳送一個訊號，父程序在接收到訊號後，會將記憶體快取中的所有命令追加到新的AOF檔案中。

　　　　5、Redis用新的AOF替換原有的AOF。

如何選擇使用哪種持久化

　　1、如果你對資料的安全性要求非常高，那麼建議兩種都適用。

　　2、如果你可以承受數分鐘的資料損失，那麼就可以使用rdb

　　3、使用AOF

notice：redis官網有這樣一段話：因為以上提到的種種原因， 未來我們可能會將 AOF 和 RDB 整合成單個持久化模型。或許很快，我們就不用糾結使用哪種持久化了。

從RDB切換到AOF

　　1、為現有的rdb檔案建立一個備份，並將備份放到一個安全的地方

　　2、redis-cli: config set appendonly yes 執行這個命令時，redis會阻塞，知道AOF檔案建立完成，然後新的寫入命令會被追加到新的AOF檔案中。

　　3、redis-cli: config set save "" 關閉RDB持久化是可選的，因為你完全可以同時開啟RDB和AOF這兩種持久化功能。

　　4、記得把前面的修改同步到redis.conf配置檔案中，否則redis重啟後，config set設定的配置就失效了。

備份redis資料及容災

　　牢記：確保你的資料由完整的備份。 磁碟故障，節點失效， 諸如此類的問題都可能讓你的資料消失不見， 不進行備份是非常危險的。

　　因為RDB的工作原理，所以redis對於資料備份是非常友好的。無論何時，複製RDB檔案是絕對安全的。

　　　　1、建立一個定期任務（cron job）， 每小時將一個 RDB 檔案備份到一個資料夾， 並且每天將一個 RDB 檔案備份到另一個資料夾。

　　　　2、確保快照的備份都帶有相應的日期和時間資訊， 每次執行定期任務指令碼時， 使用 find 命令來刪除過期的快照： 比如說， 你可以保留最近 48 小時內的每小時快照， 還可以保留最近一兩個月的每日快照。

　　　　3、至少每天一次， 將 RDB 備份到你的資料中心之外， 或者至少是備份到你執行 Redis 伺服器的物理機器之外。

　　資料備份了之後，為了做到容災，你可以將備份後的資料放到第三方資料中心。