# 虎年行大運 - 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 恢復載入速度 | 快 | 慢 |
| 資料安全性 | 可能丟失資料 | 由策略決定 |
| 適用場景 | 擁有特定時間可以進行持久化處理，或資料量大且資料重要性不高 | 資料重要性高且十分看重資料完整性 |

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

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `Redis`,`w3HexSchool`