虎年行大運 - Redis - 資料持久化處理 RDB & AOF

【主題】

前面介紹了 Redis 的機制與操作指令之後，來講講緩存資料的持久化處理部分，因為 Redis 存的資料都是緩存，意思即是當設備系統有問題需要重啟的時候，這些緩存會跟著一起消失，相信這絕對不是工程師樂見的事情，這些資料不論是為了減輕併發流量、抑或是提升系統運作效能，或多或少都有其存在意義，且若情況是系統當機的重啟，那正在操作系統的使用者，將會因為資料遺失的關係而對系統失去信心，這絕對是業務上不想碰到的、難以挽回的狀況。

因此就算只是緩存，也有必要慎重待之，確保這些資料不因重啟關係而失去，就是這一篇文章要講的持久化處理

當然，如果完全存放的是丟失也沒問題的資料的話…那這篇可以跳過了^^"

回歸正題~

Redis 提供了兩種方式做持久化處理，而兩種方式可以並存啟用，分別是以下的 RDB & AOF

【RDB 資料快照】

RDB 全名 Redis DataBasa File

Redis 在指定的時間，將此刻的緩存資料做 snapshot，簡單來說就是將這些資料寫成一份 .rdb 檔案，當 Redis 若有重啟的情況會來讀取這份檔案的內容，重新寫入緩存中。

啟動方式

透過下達以下兩種指令之一，去告知 Redis 創建 rdb 快照檔案

• save 同步指令，一經啟動後，Redis 會阻斷所有客戶端的請求，並將資料寫入檔案中。
• bgsave 非同步指令， Redis 會 forks 一個子程序作 save，期間仍能接收其他請求，但因子程序與其他請求為同步處理，因此當處理到該子程序時，仍然會阻擋客戶端的請求。

另可在 Config 檔案中可以設定當 bgsave 失敗的話是否回應異常
stop-writes-on-bgsave-error [yes/no]

除了操作指令以外，還有一種為修正在 Redis config 檔案內的設定，透過自定義的條件的方式啟動，但不建議設定過短的時間或次數條件，因為太常被觸發會導致頻繁寫入，進而影響伺服器效能。而太長的時間或次數條件則可能導致資料丟失的問題。

redis.conf

save [seconds] [count]
bgsave [seconds] [count]

e.g.
save 60 100   60秒檢查一次，若達100次寫入後，觸發save指令
save 10 1000  10秒檢查一次，若達1000次寫入後，觸發save指令

這種方式需要在啟動 Redis 的時候一併告知啟動的 Config 檔案

redis-server [Config file location]

e.g.
redis-server redis.conf

.rdb 檔案生成與處理

.rdb 檔案的生成順序如以下，

1. 生成暫時 .rdb 檔案
2. 開始寫入資料
3. 完成寫入，置換正式的 .rdb 檔案
4. 刪除被置換的 .rdb 檔案

檔案預設的名稱為 dump.rdb

另可在 Config 檔案中設定是否針對 .rdb 檔案進行壓縮處理，若有設定 yes，則會使用 LZF 演算法進行檔案的壓縮，節省佔用空間
redis.conf

rdbcompression [yes/no]

【AOF 操作紀錄】

AOF 全名 Append-Only File

與 RDB 儲存資料不同，AOF 專門儲存資料的操作，這些操作的紀錄會儲存到一份名為 .aof 的檔案中。當 Redis 重啟的時候，會載入 .aof 檔案並開始按順序執行操作，達到資料備援的效果。

.aof 也因為儲存的是操作紀錄的關係，執行速度較慢，檔案也較肥大。檔案越肥大，載入的速度就會較慢。因此 Redis 預設是不啟用 AOF 的。

但若 Redis 重啟，則 AOF 的檔案會是 Redis 優先讀取的對象。

啟動方式

Redis 預設是不啟動 AOF 的，需要到 Config 檔案中修正設定啟用。

redis.conf

# 啟用 AOF 
appendonly yes

# 設定檔案名稱
# e.g. appendfilename "redisAOF.aof"
appendfilename "[File Name]"

# 寫入策略
# 有三種可選，分別為 always, everysec, no
# 預設為 everysec
appendfsync [Strategy]

# 是否重寫 .aof 檔案
# 預設不重寫
no-appendfsync-on-rewrite [yes/no]

# 重寫條件
# 當達到與上一次重寫的百分比
# 當達到最小重寫的空間時
auto-aof-rewrite-percentage [0~100]
auto-aof-rewrite-min-size [XXX mb]

# .aof 儲存的目錄
dir ~/redis/

三種操作策略說明

• always 客戶端的每一次操作都寫入，策略本身為同步處理，執行緒安全，但每次都有 I/O 因此很慢
• everysec 每秒寫入一次，為非同步處理，若有當機狀況則會失去最後一秒的資料
• no 讓系統決定何時作業，也是最不安全的設定，但速度可以與 RDB 媲美

重寫的處理

重複的操作指令會讓 .aof 快速的增肥，因此若有開啟重寫功能的話，AOF 會自動判定是否要將部分操作指令給覆寫為新的簡短指令，減少操作紀錄儲存量。

e.g.
incr number 1
incr number 2
incr number ...
incr number 9999

就有可能被覆寫為
set number 9999

但重寫的開啟也會導致每次執行 AOF 的時候都做一次判讀，因此會大大的拖垮速度，預設為 no 就是不開啟這項服務。

可以透過推送指令強制系統執行重寫

bgrewriteaof

設定與優缺比較

項目	RDB	AOF
預設	開啟	關閉
儲存對象	資料	操作
儲存檔案	.rdb	.aof
儲存空間	小	大
儲存速度	快	慢
Redis 恢復載入優先序	低	高
Redis 恢復載入速度	快	慢
資料安全性	可能丟失資料	由策略決定
適用場景	擁有特定時間可以進行持久化處理，或資料量大且資料重要性不高	資料重要性高且十分看重資料完整性

結語

Redis 的使用設定與使用情境一直都蠻考驗後端工程師的經驗，因此好好學會基本的知識對於未來很有幫助!

首頁 Kai 個人技術 Hackmd

tags: Redis,w3HexSchool