Redis持久化

Redis包含3中持久化方案: RDB, AOF, RDB與AOF混合使用

RDB

RDB: 將內存中數據生成快照形式, 將其保存到.rdb文件中, 關注點是數據

• 使用命令執行RDB過程
  在保存.rdb文件之前還需要修改redis.conf配置文件, 修改項如下:

dbfilename dump.rdb //配置.rdb文件名, 通常設置為dump.端口號.rdb dir /www/server/redis/data //設置rdb文件的存儲位置 rdbcompression yes //設置存儲到本地時, 是否壓縮(默認壓縮), 使用LZF壓縮 rdbchecksum yes //設置是否在讀寫.rdb文件時, 進行格式校驗, 默認開啟, 關閉可節約10%時間, 但存在風險

• 保存指令

save //手動執行保存操作 bgsave //在后臺執行保存操作

二者執行過程如下:

• save執行過程
  
  注: redis是單線程, 執行save操作的時候會造成阻塞問題, 會嚴重影響其性能, 通常不使用.
  解決刪除上述問題, 使用bgsave指令.
• bgsave指令工作原理如下:
  
  bgsave與save的區別:

redis主線程操作save指令; redis生成子進程操作bgsave指令

• 自動執行RDB
  在redis.conf配置文件中編寫如下配置:

save second changes //在second時間內, 若key發生changes次變化, 那么就進行持久化操作.

配置redis.conf進行rdb操作, 內部使用的還是bgsave指令, 執行流程如下

注: save需要根據實際業務情況進行配置, save執行頻率過高或者過低都會造成性能問題. save配置中的second與changes通常設置為互補的關系, 使用debug reload, shutdown指令會自動執行bgsave(如果沒有開啟AOF持久化功能)

• RDB優缺點

優: 存儲效率高, 數據恢復速度快 缺: 服務器宕機時會出現部分數據丟失, 使用save或者bgsave都將會導致性能損失, redis的rdb文件版本不統一.

AOF

AOF: 使用日志的方式記錄redis執行的命令, 當出現宕機時, 能盡量避免數據丟失的情況, 很好解決了RDB的問題, 但是AOF存在數據恢復較慢的問題.

• AOF執行步驟
  
• AOF寫數據的3中策略(AOF寫數據也是使用fork處理, 與bgsave一樣)

always: 每次的寫操作命令都同步到AOF文件中, 數據誤差零, 但性能低下. everysec: 每秒將命令緩存區中內容同步到.aof文件中, 會丟失1s的數據, 準確性較高, 性能較好, 默認配置. no: 使用系統控制, 整體過程不可控.

• AOF相關配置

appendonly yes|no //yes代表aof功能開啟, 默認不開啟 appendfsync always|everysec|no //設置AOF寫數據策略 appendfilename fileName //設置.aof文件名 dir path //.aof文件保存位置

• AOF重寫
  AOF重寫: 對同一個數據操作的指令壓縮為一條指令, 解決.aof文件體積過大, 增加磁盤利用率, 提高IO性能.
  例: set name A; set name B; set name C; ===> set name C;
• AOF重寫方式

//輸入命令進行手動重寫 bgrewriteaof//配置redis.conf進行自動重寫 auto-aof-rewrite-min-size size //當前緩存區中指令數大于最小值, 就重寫 auto-aof-rewrite-percentage percent //當尺寸的比例, 大于指令值就重寫

注: AOF手動重寫過程調用fork函數, 生成子進程, 子進程進行.aof重寫, 流程與bgsave一樣.

• AOF工作流程:
  
• AOF重寫流程:
  
  注:

AOF緩沖區同步策略由appendfsync控制. 系統調用write和fsync說明: write操作會觸發延遲寫機制, Linux在內核提供頁緩沖區用來提高IO性能, write操作在寫入系統緩沖區后直接返回, 當出現宕機的情況會導致緩沖區內容丟失. fsync對單個文件操作, 使用強制磁盤同步.保證數據持久化

RDB與AOF區別

持久化方式RDBAOF

占用存儲空間	小(數據壓縮)	大(數據重寫)
存儲速度	慢	快
恢復速度	快	慢
數據安全性	存在數據丟失	依賴于寫策略
資源消耗	高/重量級	低/輕量級
啟動優先級	低	高

RDB與AOF的選擇

數據敏感: 使用AOF(.aof文件較大, 數據恢復速度慢)
數據呈階段性有效: 使用RDB(對數據丟失不敏感, 數據恢復速度快)
綜合比對:

• RDB與AOF的選擇實際上是在做一種權衡，每種都有利有弊
• 如不能承受數分鐘以內的數據丟失，對業務數據非常敏感，選用AOF
• 如能承受數分鐘以內的數據丟失，且追求大數據集的恢復速度，選用RDB
• 災難恢復選用RDB
• 雙保險策略，同時開啟 RDB 和 AOF，重啟后，Redis優先使用 AOF 來恢復數據，降低丟失數據的量

持久化應用場景

Tips 1：redis 應用于搶購，限購類、限量發放優惠卷、激活碼等業務的數據存儲設計
Tips 2：redis 應用于具有操作先后順序的數據控制
Tips 3：redis 應用于最新消息展示
Tips 4：redis 應用于基于黑名單與白名單設定的服務控制
Tips 5：redis 應用于計數器組合排序功能對應的排名
Tips 6：redis 應用于即時任務/消息隊列執行管理

Redis事務

多個redis-cli操作一個redis-server就會存在事務問題.

• 事務基本操作

multi //開啟事務 exec //執行事務 discard //取消事務, 終止當前事務, 在multi與exec中間發生

注: multi必須與exec成對出現, 當開啟事務時, 加入事務的命令都進入任務隊列中, 當執行exec指令時, 才將任務隊列中的指令取出進行執行.

注: 若命令隊列中的命令書寫錯誤, 則隊列中所有的指令都不會執行, 若隊列中的命令書寫正確但是運行錯誤(例如: set name A; name不存在), 正確的命令都會執行, 錯誤的命令不會執行, 已經執行完的命令不會自動回滾, 需要在代碼中手動實現.

• 手動回滾事務

記錄操作之前數據狀態, 設置修改的值可以進行恢復.

• 鎖
  在執行事務時為共享資源加鎖, 防止其他redis-cli對共享資源修改.

watch key1 [key2...] //對key加鎖, 在一個事務內, 其他redis-cli對key做修改, 則當前事務無效 unwatch //取消對所有key的監視

事務執行成功:

事務執行失敗, 在該事務下, 使用另外一個redis-cli修改list中的值, 當該事務exec, 出現失敗.

• 監控具體的數據是否被修改(watch只能監控key對應value的變化, 不能監控具體的數據)

setnx lock lockValue//設置lock(可以將這里的lock理解為就是string), 如果lock已經存在, 則返回0 del lock //刪除lock

當1號客戶端設置lock時, 2號客戶端對嘗試修改lock, 但是修改失敗, 說明該lock已經存在, 此時2號客戶端停止操作.
注: 利用setnx的返回值, 對于返回設置成功的, 擁有控制權, 進行下一步具體業務操作, 對于返回失敗的, 不具有控制權, 進行排隊或等待.當擁有控制的客戶端執行完所有操作后, 使用del刪除lock, 此時另外的客戶端就擁有了資源的控制權.

• 使用expire為lock添加時間期限, 防止setnx后, 服務器宕機, lock一直存在, 其他客戶端無法獲取lock進行操作

expire lock seconds //為setnx的鎖添加seconds時間限定, 超出該時間后, 自動放棄鎖 pexpire lock milliseconds //同上, 添加milliseconds時間

注: 通常操作都是毫秒級別, 不應將鎖定時間設置過大, 鎖定時間設置=>最大耗時120%+平均網絡延遲110%

Redis刪除策略

• redis 所有數據放置在內存中, 可使用TTL命令獲取數據狀態

XX: 具有有效性的數據 -1: 永久有效數據 -2: 已經過期, 刪除, 未定義的數據

• redis expires數據分布結構:
  
• 數據刪除策略如下:

定時刪除:數據到達過期時間時, 定時器啟動刪除.優: 節省內存; 缺: CPU壓力較大, 影響吞吐量拿性能換空間惰性刪除:數據到達過期時間, 不進行處理, 等再次訪問該數據時再刪除優: 節約CPU; 缺: 內存壓力大拿空間換性能.定期刪除(定時刪除與惰性刪除的折中方案)周期輪詢redis庫中時效性數據, 采用隨機抽取, 利用過期數據占比控制刪除頻率.優: 修改配置文件數據, 可做到性能與內存的最優.周期性抽查內存空間

• 定期刪除
  
• activeExpireCycle()函數對每個db的expires空間進行檢查, 每次執行250ms/server.hz
• 檢查一個expires時, 隨機挑選w個key(w = ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP屬性)
  • 若key過期, 則刪除key
  • 若一輪中刪除的key數量>=w*25%, 則循環該過程
  • 若一輪中刪除的key數量<=w*25%, 則進入下一個expires空間
• 使用current_db記錄當前activeExpireCycle()進入哪一個expires空間
• 當activeExpireCycle()執行時間到了, 下一次的activeExpireCycle執行就從current_db開始執行

逐出算法

逐出算法: redis執行每一個命令之前, 都調用freeMemoryIfNeeded()進行內存檢測, 判斷是否充足, 內存不足時, 將臨時刪除一些數據, 然后保存新生成的數據.
逐出算法不能100%成功, 不成功則反復執行, 對所有數據進行嘗試后, 若不能達到清除的要求, 則輸出OOM錯誤.

• 逐出算法相關配置

maxmemory //最大可使用內存, 默認為0, 不限制, 通常設置該值為50%以上 maxmemory-samples //選取待刪除數據的個數, 使用隨機抽取, 而不是全庫掃描, 提高性能 maxmemory-policy //達到最大內存后, 對挑選出來的數據進行刪除檢測易失數據:volatile-lru: 挑選最近最少使用的數據淘汰volatile-lfu: 挑選最近使用次數最少的數據淘汰volatile-ttl: 挑選將要過期的數據淘汰檢測全庫數據:allkeys-lru: 挑選最近最少使用的數據淘汰allkeys-lfu: 挑選最近使用次數最少的數據淘汰all-random: 任意數據淘汰放棄數據驅逐no-enviction: 放棄刪除, 會導致OOM

使用info命令, 查看控制信息, 然后配置逐出策略

總結

以上是生活随笔為你收集整理的Redis持久化_Redis事务_Redis删除策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。