Redis持久化

• Redis是一個in-memory的data store，在記憶體中操作與儲存讓其可以達到很快的效能，但如果關閉Redis時．記憶體中的資料將會消失．

  • 情境一：當Redis用途在cahce時，資料可能遺失了後再載入即可．

  • 情境二：如果Redis當作資料庫就必須要讓資料可以永久保存起來，這時候持久化就相當重要，以便在Redsi服務啟動時可以把需要的資料完整的載入提供所需．

  • 情境三：有個額外的情境也需要特別關注，雖然cache資料沒有了我們可以直接重新把需要的資料透過資料庫取得並載入，但是資料量如果有10G甚至更多的時候，且這樣在cache中的資料應該是需要常用到的資料，這樣Redis服務在啟用的時候很快，但要把常用資料都載入需要耗費非常多的時間和資料庫的資源，這個情境下也就要考慮是否使用持久化的方式來加快載入減少資源的花費．

• 持久化有以下幾個模式，可以在Redis正常或不正常關閉時，能夠繼續保有資料．

  • 不需要持久化
  • RDB
  • AOF
  • RDB+AOF

Redis持久化模式->不需要持久化

這個模式適用於資料不是特別重要，也就是允許失去所有資料也沒關係，可以選擇此模式．

Redis持久化模式->RDB

此模式會在特定間隔時間條件達到時，將Redis在記憶體中的內容保存到RDB檔案(二進位格式)中．也就是在特定時間點的快照．當Redis服務啟動時，可以讀取RDB檔案來恢復到記憶體中．

• 優點：

  • RDB是存放Redis某個時間點的快照，適合用在備份或是異地備份，提供災難復原使用，且只要備份一個檔案即可．
  • RDB進行中對Redis效能的影響很小，因為Redis的父Process會fork一個子Process獨立進行產生RDB，父Process不需要進行IO操作．
  • 當Redis重新啟動時，如有大量資料的情況下，RDB比AOF有更短的啟動時間．
  • 在Replica架構下，Redis重新啟動或failover後，RDB支援部分再同步機制．
    (部分再同步指的是可以繼續從原來的Master同步異動直到一致，只有RDB才可以適用，AOF模式不可以使用此機制．)

• 缺點：

  • 因為RDB是某個時間點的快照，不是最新的內容，故有可以會發生資料遺失的狀況．
  • 如果資料量極大且產生快照RDB的頻率太高時，有可以會因此耗用較多的CPU效能，影響到父Process的客戶端操作回應．

• 快照設定

# 取得目前快照設定
127.0.0.1:6379> config get save
1) "save"
2) "3600 1 300 100 60 10000"

# 取得目前rdb的檔案名稱
127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump.rdb"

# 取得目前rdb檔案存放位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/redis/bin"

• 馬上執行RDB

# 馬上產生rdb檔案(測試使用，實際上會依照設定的間隔條件到達時進行)
127.0.0.1:6379> save
OK

# 馬上產生rdb檔案(fork子Process於背景執行，如果目前正在進行rdb or aof則會回傳錯誤)
bgsasve

# 取得最近一次save的時間點，當回傳的unixtimestamp不再變化時，表示bgsave已經完成
lastsave

# 排程產生rdb檔案(如果目前aof正在進行中，則會回傳OK，此次RDB則不會執行，會排程安排下次執行)
bgsave schedule

• 特定間隔執行RDB

可以在redis.conf檔案中設定snapshot區段的相關設定．

• 關閉Redis時產生最後的RDB

# 預設關閉服務時會執行產生RBD
shutdown save

# 關閉服務時不執行產生RDB
shutdown nosave

• 啟動Redis Server時會載入RDB