redis的資料持久化

標籤：redis資料持久化

就目前自己的理解redis和memcache的區別就是redis可以資料持久化，支援的資料類型有5種

所以就資料持久化這塊可以好好瞭解一下

我們安裝的redis的2.6版本，安裝之後預設就已經開啟了rdb

資料持久化分rdb和aof

快照:(snapshotting)它將某一時刻的的所以資料寫入硬碟

只追加檔案:(append-only file) 他會在執行寫命令時，將會把寫命令複製到磁碟裡面

快照（rdb）：

save 900 1     #900秒時間，至少有一條資料更新，則儲存到資料檔案中

save 300 10    #300秒時間，至少有10條資料更新，則儲存到資料檔案中

save 60 10000  #60秒時間，至少有10000條資料更新，則儲存到資料檔案中

rdbcompression yes  #指定儲存至本機資料庫時是否壓縮資料，預設是yes，redis採用LZF壓縮，如果為了節省CPU時間 #可以關閉該選項，但會導致資料庫檔案扁的巨大

dbfilename dump.rdb #指定rdb儲存到本機資料庫檔案名稱

stop-writes-on-bgsave-error yes  #當硬碟因為許可權等原因無法寫入時，停止寫入

rdbchecksum yes    #對rdb檔案進行校正

建立快照的方式有以下4種：

1，用戶端執行BESAVE，服務端會fork一個子進程來負責將快照寫入硬碟，父進程繼續處理寫請求

2，用戶端執行save，服務端會在建立快照完畢之前不在響應其他的命令，一般沒有足夠的記憶體去執行BESAVE的情況下才會去執行save，一般沒有用這個

3，當redis服務端接受了一個shutdown的時候，或收到一個標準TERM訊號（kill）的時候,會執行一個SAVE，會阻塞所以用戶端請求，然後執行完save之後關閉服務

4，當作redis主從的時候（請看我的另一篇部落格redis主從同步)

個人感覺如果對資料的儲存有特別高的要求，就不要用rdb可以用aof

只追加檔案(aof):

#appendonly no   #是否在每次更新操作後進行日誌記錄，是否開啟啟用aof。

# appendfsync always       # always：表示每次更新操作後手動調用fsync()將資料寫到磁碟（慢，安全，最好不要用這個會很損害硬碟的） 

#appendfsync everysec       # everysec：表示每秒同步一次（折衷，預設值）

#appendfsync no             # no：表示等作業系統進行資料緩衝同步到磁碟（快）\

#

#auto-aof-rewrite-percentage 100

#auto-aof-rewrite-min-size 64mb

當aof體積大於64mb的時候，並且aof檔案的體積比上次重寫之後的體積大於至少一倍（100%）的時候，redis執行bgrewriteaof

no-appendfsync-on-rewrite   no#如下面的解釋

bgrewriteaof機制，在一個子進程中進行aof的重寫，從而不阻塞主進程對其餘命令的處理，同時解決了aof檔案過大問題。

現在問題出現了，同時在執行bgrewriteaof操作和主進程寫aof檔案的操作，兩者都會操作磁碟，而bgrewriteaof往往會涉及大量磁碟操作，這樣就會造成主進程在寫aof檔案的時候出現阻塞的情形，現在no-appendfsync-on-rewrite參數出場了。如果該參數設定為no，是最安全的方式，不會遺失資料，但是要忍受阻塞的問題。如果設定為yes呢？這就相當於將appendfsync設定為no，這說明並沒有執行磁碟操作，只是寫入了緩衝區，因此這樣並不會造成阻塞（因為沒有競爭磁碟），但是如果這個時候redis掛掉，就會遺失資料。丟失多少資料呢？在linux的作業系統的預設設定下，最多會丟失30s的資料。

因此，如果應用系統無法忍受延遲，而可以容忍少量的資料丟失，則設定為yes。如果應用系統無法忍受資料丟失，則設定為no

本文出自 “王小酸” 部落格，轉載請與作者聯絡！

redis的資料持久化