# 虎年行大運 - 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`