redis（三）持久化
簡介
1.什麼是持久化
利用永久性儲存介質將資料進行儲存，在特定的時間將儲存的資料進行恢復的工作機制成為持久化
2.為什麼要持久化
防止資料的以外丟失，確保資料安全性，做好災備的工作
3.持久化過程中儲存什麼
RDB:將當前資料狀態進行儲存模組找形式，儲存資料結果，儲存格式簡單，關注點在資料上
AOF:將資料的操作過程進行儲存，日誌形式，儲存操作過程，儲存格式複雜，關注點在資料的操作過程
前期準備
1.下載redis映象
2.建立資料夾
mkdir /usr/local/docke
mkdir /usr/local/docker/redis
mkdir /usr/local/docker/redis/conf/
vi /usr/local/docker/redis/conf/redis-6379.conf -->redis-6376的內容可以在官網http://download.redis.io/redis-stable/redis.conf 下載
mkdir /usr/local/docker/redis/data/ -- 建立資料掛載目錄
3.修改配置檔案
bind 127.0.0.1 #註釋掉這部分，這是限制redis只能本地訪問
protected-mode no #預設yes，開啟保護模式，限制為本地訪問
daemonize no#預設no，改為yes意為以守護程序方式啟動，可後臺執行，除非kill程序，改為yes會使配置檔案方式啟動redis失敗
requirepass 密碼 #配置redis訪問密碼 重啟後輸入密碼為 auth 密碼
4.啟動
docker run
-p 6379:6379 // 埠對映
--name myredis //制定容器名稱
-v /usr/local/docker/redis/conf:/etc/redis //配置檔案對映
-v /usr/local/docker/redis/data:/data //資料對映
-d redis //後臺啟動
redis-server /etc/redis/redis-6379.conf //以配置檔案的方式啟動redis
RDB（全量資料，關注點資料）
1.save指令
1.1指令
save -->手動執行一次儲存操作
save以後會多個dump.rdb的檔案
1.2.save指令相關配置
dbfilename dump.rdb #設定本地資料庫檔名，預設值為dump.rdb
通常設定為dump-埠號.rdb
dir #設定儲存.rdb檔案的路徑
通常設定成儲存空間較大的目錄中，目錄名稱data
rdbcompression yes #設定儲存至本地資料庫時是否壓縮資料，預設為yes門採用LZF壓縮
通常為開啟狀態，如果設定為NO，可以節省CPU執行時間，但是會導致儲存的檔案變大
rdbchecksum yes #設定是否機型RDB檔案格式校驗，該校驗過程在寫檔案和讀檔案過程中均進行
通常預設開啟，如果要設定為NO，可以節約讀寫過程中約10% 時間消耗，但是存在一定的資料損壞的風險
1.3備註
save指令的執行會組掃當前redis伺服器，知道RDB過程完成為止，可能會造成長時間阻塞，線上環境不建議使用
2.bgsave指令
2.1指令
bgsave -->手動儲存後臺執行，不是立即執行
2.2工作原理
備註：bgsave命令是針對save阻塞問題的我話，redis內部所有涉及到RDB操作都才用bgsave的方式，save命令可以放棄使用
2.3bgsave指令相關配置
stop-writes-on-bgsave-error yes #後臺儲存過程中如果出現錯誤現象，是否停止儲存操作
通常預設為開啟狀態
3.save配置
save second changes #滿足限定時間範圍內key的變化數量達到指定數量即進行持久化
second為監控時間
changes監控key的變化量
例：
save 900 1
save 300 10
save 60 10000
備註：save配置根據實際業務情況機型設定，如果頻率過高或頻率過低都會出現效能問題
save配置中對於second和changes設定通常具有互補對應關係，如時間長變更次數小和時間短變更次數多儘量不要設定成包含行關係
save配置啟動後執行的是bgsave操作
4.RDB三種方式對比
RDB其他啟動方式
1.全量複製 如主從複製
2.伺服器執行過程中重啟 debug reload
3.關閉伺服器是制定儲存資料 shutdown save
5.RDB的優缺點
5.1優點
RDB是一個緊湊壓縮的二進位制檔案，儲存效率較高
RDB內部儲存的是redis在某個時間點的資料快照，非常適合用於資料備份，全量複製等場景
RDB恢復資料的速度要比AOF快很多
應用：伺服器中每X小時執行bgsave備份，並將RDB檔案拷貝到遠端機器中，用於災難恢復。
5.2缺點
RDB方式無論是執行指令還是利用配置，無法做到實時持久化，具有較大的可能性丟失資料
bgsave指令每次執行要執行fork操作建立子程序，要犧牲掉一些效能
Redis的眾多版本中未進行RDB檔案格式的版本統一，有可能出現各版本服務之間資料格式無法相容現象
AOF（關注點，操作過程）
1.介紹
AOF持久化：一獨立日誌的方式記錄每次命令，重啟時再重新執行AOF檔案中命令以達到恢復資料的目的
AOF主要的作用問了解決資料持久化的實時性
AOF存在快取區，定時將快取寫入AOF檔案中
2.AOF寫資料三種策略
2.1 always
每次寫入操作均同步到AOF檔案中，--->資料零誤差，效能較低，不建議使用
2.2 everysec
每次講快取區中的指令同步到AOF檔案中 -->資料準確性較高，效能較高，建議使用，也是預設配置
在系統突然停機的情況下丟失1秒內的資料
2.2 no
由作業系統控制每次同步到AOF檔案的週期，整體過程不可控
3.AOF功能開啟
appendonly yes|no #是否開啟AOF持久化功能，預設為不開啟
appendfsync always|everysec|no #配置AOF寫資料策略
appendfilename filename #AOF持久化檔名，預設名稱為 appendonly.aof，建議配置為appendonly-埠號.aof
dir #AOF持久化檔案儲存路徑，與RDB持久化檔案保持一致即可
發現已經寫檔案成功了
4.AOF重寫
隨著命令不斷寫入AOF檔案中，檔案會越來越大，為了解決這個問題，則引入了AOF重寫機制壓縮檔案體積，AOF檔案重寫是將redis程序中的資料轉化為寫命令同步到新AOF檔案的過程，簡單來說就是將對資料的若干條指令執行結果轉化為最終結果資料對應的指令
作用：
降低磁碟佔用量，提高磁碟利用率
提交持久化效率，降低持久化寫時間，提高IO效能
降低資料恢復用時，提交資料恢復效率
4.1指令
bgrewriteaof --手動重寫
新增資料
檢視檔案
執行重寫
檢視檔案
變小了有沒有
4.2規則
程序內已超時的資料不再寫入檔案
忽略無效指令，重寫時使用程序內資料直接生成，這樣新的AOF檔案只保留最終資料的寫入命令 如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
對同一資料的多條寫命令合併為一條命令 如lpush list1 a、lpush list1 b、 lpush list1 c 可以轉化為：lpush list1 a b c。 為防止資料量過大造成客戶端緩衝區溢位，對list、set、hash、zset等型別，每條指令最多寫入64個元素
4.3配置
auto-aof-rewrite-min-size size # 超過大小重寫
auto-aof-rewrite-percentage percentage #超過百分比重寫
自動重寫觸發比對引數（ 執行指令info Persistence獲取具體資訊 ）
aof_current_size
aof_base_size
自動重寫觸發條件
4.4重寫流程
RDB和AOF對比總結
1.對資料非常敏感，建議使用預設的AOF持久化方案
1.1 AOF持久化策略使用everysecond，每秒鐘fsync一次。該策略redis仍可以保持很好的處理效能，當出 現問題時，最多丟失0-1秒內的資料。
1.2 注意：由於AOF檔案儲存體積較大，且恢復速度較慢
2.資料呈現階段有效性，建議使用RDB持久化方案
2.1 資料可以良好的做到階段內無丟失（該階段是開發者或運維人員手工維護的），且恢復速度較快，階段 點資料恢復通常採用RDB方案
2.2注意：利用RDB實現緊湊的資料持久化會使Redis效能降的很低，慎重使用；
3 綜合比對
3.2 RDB與AOF的選擇實際上是在做一種權衡，每種都有利有弊
3.3如不能承受數分鐘以內的資料丟失，對業務資料非常敏感，選用AOF
3.4如能承受數分鐘以內的資料丟失，且追求大資料集的恢復速度，選用RDB
3.5災難恢復選用RDB 雙保險策略，同時開啟 RDB 和 AOF，重啟後，Redis優先使用 AOF 來恢復資料，降低丟失資料的量