1. 程式人生 > >Redis如何做持久化的?

Redis如何做持久化的?

redis提供兩種方式進行持久化,一種是RDB持久化(原理是將Reids在記憶體中的資料庫記錄定時dump到磁碟上的RDB持久化),另外一種是AOF(append only file)持久化(原理是將Reids的操作日誌以追加的方式寫入檔案)。

bgsave做映象全量持久化,aof做增量持久化。因為bgsave會耗費較長時間,不夠實時,在停機的時候會導致大量丟失資料,所以需要aof來配合使用。在redis例項重啟時,優先使用aof來恢復記憶體的狀態,如果沒有aof日誌,就會使用rdb檔案來恢復。

Redis會定期做aof重寫,壓縮aof檔案日誌大小。

二者的區別

RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟,實際操作過程是fork一個子程序,先將資料集寫入臨時檔案,寫入成功後,再替換之前的檔案,用二進位制壓縮儲存。

AOF持久化以日誌的形式記錄伺服器所處理的每一個寫、刪除操作,查詢操作不會記錄,以文字的方式記錄,可以開啟檔案看到詳細的操作記錄。

二者優缺點

RDB存在哪些優勢呢?

1). 一旦採用該方式,那麼你的整個Redis資料庫將只包含一個檔案,這對於檔案備份而言是非常完美的。比如,你可能打算每個小時歸檔一次最近24小時的資料,同時還要每天歸檔一次最近30天的資料。通過這樣的備份策略,一旦系統出現災難性故障,我們可以非常容易的進行恢復。

2). 對於災難恢復而言,RDB是非常不錯的選擇。因為我們可以非常輕鬆的將一個單獨的檔案壓縮後再轉移到其它儲存介質上。

3). 效能最大化。對於Redis的服務程序而言,在開始持久化時,它唯一需要做的只是fork出子程序,之後再由子程序完成這些持久化的工作,這樣就可以極大的避免服務程序執行IO操作了

4). 相比於AOF機制,如果資料集很大,RDB的啟動效率會更高。

RDB又存在哪些劣勢呢?

1). 如果你想保證資料的高可用性,即最大限度的避免資料丟失,那麼RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象,此前沒有來得及寫入磁碟的資料都將丟失。

2). 由於RDB是通過fork子程序來協助完成資料持久化工作的,因此,如果當資料集較大時,可能會導致整個伺服器停止服務幾百毫秒,甚至是1秒鐘。

AOF的優勢有哪些呢?

1). 該機制可以帶來更高的資料安全性,即資料永續性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事實上,每秒同步也是非同步完成的,其效率也是非常高的,所差的是一旦系統出現宕機現象,那麼這一秒鐘之內修改的資料將會丟失。而每修改同步,我們可以將其視為同步持久化,即每次發生的資料變化都會被立即記錄到磁碟中。可以預見,這種方式在效率上是最低的。至於無同步,無需多言,我想大家都能正確的理解它。

2). 由於該機制對日誌檔案的寫入操作採用的是append模式,因此在寫入過程中即使出現宕機現象,也不會破壞日誌檔案中已經存在的內容。然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題,不用擔心,在Redis下一次啟動之前,我們可以通過redis-check-aof工具來幫助我們解決資料一致性的問題。

3). 如果日誌過大,Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中,同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證資料安全性。

4). AOF包含一個格式清晰、易於理解的日誌檔案用於記錄所有的修改操作。事實上,我們也可以通過該檔案完成資料的重建。

AOF的劣勢有哪些呢?

1). 對於相同數量的資料集而言,AOF檔案通常要大於RDB檔案。RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。

2). 根據同步策略的不同,AOF在執行效率上往往會慢於RDB。總之,每秒同步策略的效率是比較高的,同步禁用策略的效率和RDB一樣高效。

二者選擇的標準,就是看系統是願意犧牲一些效能,換取更高的快取一致性(aof),還是願意寫操作頻繁的時候,不啟用備份來換取更高的效能,待手動執行save的時候,再做備份(rdb)。rdb這個就更有些 eventually consistent的意思了。

常用配置

RDB持久化配置

RDB核心規則配置(重點)

save 900 1              #在900秒(15分鐘)之後,如果至少有1個key發生變化,則dump記憶體快照。

save 300 10            #在300秒(5分鐘)之後,如果至少有10個key發生變化,則dump記憶體快照。

save 60 10000        #在60秒(1分鐘)之後,如果至少有10000個key發生變化,則dump記憶體快照。

指定本地資料庫檔名,一般採用預設的 dump.rdb

dbfilename dump.rdb

指定本地資料庫存放目錄,一般也用預設配置

dir ./

 預設開啟資料壓縮

配置儲存至本地資料庫時是否壓縮資料,預設為yes。Redis採用LZF壓縮方式,但佔用了一點CPU的時間。若關閉該選項,但會導致資料庫檔案變的巨大。建議開啟。

rdbcompression yes

觸發RDB快照

1 在指定的時間間隔內,執行指定次數的寫操作
2 執行save(阻塞, 只管儲存快照,其他的等待) 或者是bgsave (非同步)命令

通過RDB檔案恢復資料

將dump.rdb 檔案拷貝到redis的安裝目錄的bin目錄下,重啟redis服務即可。

AOF持久化配置

redis 預設關閉,開啟需要手動把no改為yes

appendonly yes

指定本地資料庫檔名,預設值為 appendonly.aof

appendfilename "appendonly.aof"

在Redis的配置檔案中存在三種同步方式,它們分別是:

appendfsync always     #每次有資料修改發生時都會寫入AOF檔案。

appendfsync everysec  #每秒鐘同步一次,該策略為AOF的預設策略。

appendfsync no          #從不同步。高效但是資料不會被持久化。

配置重寫觸發機制

當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發。一般都設定為3G,64M太小了。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb