1. 程式人生 > >Redis持久化原理及配置詳解(RDB方式和AOF方式)

Redis持久化原理及配置詳解(RDB方式和AOF方式)

Redis的強大功能很大程度上是由於其將所有資料都儲存在記憶體中。為了使Redis在重啟後仍能保證資料不丟失,需要將資料從記憶體中以某種形式持久化到硬碟中。Redis支援兩種持久化方式,一種是RDB方式,一種是AOF方式。可以單獨使用其中一種或兩種結合使用。(持久化即將資料儲存到磁碟,機器宕機或者重啟資料不丟失,儲存到記憶體中的資料會丟失)

1.RDB方式持久化

1.1 RDB的概念
RDB方式是通過快照方式完成的,當符合一定條件時Redis會自動將記憶體中的所有資料進行快照並且儲存到硬碟上。進行快照的條件在配置檔案中指定,有2個引數構成:時間和改動鍵的個數,當在指定時間內被更改的鍵的個數大於指定數值時就會進行快照。RDB是Redis預設的持久化方式。

1.2 RDB的配置
在配置檔案中已經預置了三個條件

save 900 1 # 15分鐘內至少有一個鍵被更改 
save 300 10 # 5分鐘內至少有10個鍵被更改
save 60 10000 # 1分鐘內至少有10000個鍵被更改

以上條件是或的關係

預設的rdb檔案路徑是當前目錄,檔名是:dump.rdb,可以在配置檔案中修改路徑和檔名,分別是dir和dbfilename

dir ./ # rdb檔案儲存路徑
dbfilename dump.rdb # rdb檔名

如果沒有觸發自動快照,需要對Redis執行手動快照操作,SAVE和BGSAVE都是執行手動快照,但是兩者有區別:可以通過SAVE和BGSAVE命令來手動快照,兩個命令的區別是前者是由主程序進行快照,會阻塞其他請求,後者是通過fork子程序進行快照

注意:由於Redis使用fork來複制一份當前程序,那麼子程序就會佔有和主程序一樣的記憶體資源,比如說主程序8G記憶體,那麼在備份的時候,必須保證有16G的記憶體,要不然會啟用虛擬記憶體,效能非常的差。

1.3 RDB功能測試:
RDB功能測試1

這裡可能會帶來疑惑,明明已經開啟了RDB配置,為什麼Redis宕機後,資料還是丟失了呢?原因是由於沒達到RDB持久化觸發條件,所以我們手動觸發RBD後再測試,如下圖所示:
RDB功能測試2

1.4 RBD檔案的壓縮:
RDB檔案是通過壓縮的,可以通過配置rdbcompression引數來禁用壓縮,Redis預設是開啟壓縮的

壓縮:
    優點:減少磁碟儲存空間
    缺點:消耗CPU資源
不壓縮:
    優點:不消耗CPU資源
    缺點:佔用磁碟空間多

2. AOF方式持久化

2.1 AOF的概念
Redis的AOF持久化策略是將傳送到Redis服務端的每一條命令都記錄下來,並且儲存在硬碟的AOF檔案中。可以通過引數appendonly來設定是否啟用AOF。AOF檔案的位置和RDB的位置相同,都是通過dir引數設定,預設的檔名是appendonly.aof,可以通過appendfilename引數修改。

2.2 優化AOF檔案
可以使用BGREWRITEAOF命令來重寫AOF檔案。目的是去除資料的中間執行過程,儲存最終資料命令即可。

2.3 重寫策略的引數設定
auto-aof-rewrite-percentage 100
當前的AOF檔案大小超過上一次重寫的AOF檔案大小的百分之多少時會再次進行重寫,如果之前沒有重寫過,則以啟動時的AOF大小為依據。

auto-aof-rewrite-min-size 64mb
限制了允許重寫的最小AOF檔案,通常在AOF檔案很小的時候即使其中有些冗餘命令也可是可以忽略的。

2.4 檔案同步策略
檔案寫入預設情況下會先寫入到系統的快取中,系統每30秒同步一次,才是真正的寫入到磁碟,如果在這30秒伺服器宕機那資料也會丟失的

Redis可以通過配置來修改同步策略:

# appendfsync always 每次都同步(最安全但是最慢)
appendfsync everysec 每秒同步(預設的同步策略)
# appendfsync no 不主動同步,由作業系統來決定(最快但是不安全)

2.5 AOF持久化方式測試
AOF持久化方式測試
由於還沒達到RDB的持久化觸發條件 所以這裡有資料肯定用的是AOF持久化方式 到此AOF持久化成功生效