# Redis中內存淘汰策略和過期鍵刪除策略的示例分析
## 引言
Redis作為高性能的鍵值數據庫,其內存管理機制直接影響系統性能和穩定性。當內存達到上限時,Redis通過**內存淘汰策略(Eviction Policies)**決定哪些數據被移除;而**過期鍵刪除策略(Expiration Policies)**則負責清理已過期的鍵。本文將深入分析這兩類策略的工作原理,并通過實際示例演示其行為差異。
---
## 一、Redis內存淘汰策略
### 1.1 為什么需要內存淘汰?
當Redis內存使用達到`maxmemory`配置的閾值時(默認不限制),需通過淘汰機制釋放空間。通過`maxmemory-policy`參數可配置以下策略:
#### 1.1.1 不淘汰策略
- **noeviction**(默認):拒絕所有寫入命令(返回OOM錯誤),讀操作正常。
```bash
# 示例:寫入被拒絕時的錯誤響應
127.0.0.1:6379> set new_key value
(error) OOM command not allowed when used memory > 'maxmemory'.
策略名稱 | 規則描述 | 適用場景 |
---|---|---|
allkeys-lru | 從所有鍵中淘汰最近最少使用的鍵 | 熱點數據分布不均勻 |
volatile-lru | 僅從設定了過期時間的鍵中淘汰LRU | 需保留持久化數據 |
allkeys-random | 隨機淘汰所有鍵 | 無明確訪問模式 |
volatile-random | 隨機淘汰有過期時間的鍵 | 過期鍵無優先級 |
volatile-ttl | 優先淘汰剩余存活時間(TTL)最短的鍵 | 需要快速清理短期數據 |
# 配置為allkeys-lru并插入數據
127.0.0.1:6379> config set maxmemory-policy allkeys-lru
127.0.0.1:6379> set key1 val1
127.0.0.1:6379> set key2 val2
127.0.0.1:6379> get key1 # 訪問key1使其"熱度"提升
"val1"
# 當內存不足時,key2(未被訪問)會被優先淘汰
注意:Redis的LRU是近似算法,通過采樣少量鍵(默認5個)選擇最久未使用的,而非全局掃描。
INFO memory
觀察內存碎片率(mem_fragmentation_ratio
)。volatile-lru
,對緩存數據用allkeys-lru
。volatile-ttl
的CPU開銷通常高于隨機淘汰。當客戶端嘗試訪問一個鍵時,Redis會檢查其過期時間,若已過期則立即刪除。
# 示例:訪問已過期鍵
127.0.0.1:6379> setex temp_key 10 "expires_in_10s"
127.0.0.1:6379> sleep 11
127.0.0.1:6379> get temp_key # 觸發被動刪除
(nil)
缺點:如果鍵長期不被訪問,會導致內存泄漏。
Redis以每秒10次(可配置)的頻率執行以下操作: 1. 隨機抽取20個設置了過期時間的鍵。 2. 刪除其中已過期的鍵。 3. 如果超過25%的鍵過期,則重復步驟1。
# 通過修改hz參數調整頻率
127.0.0.1:6379> config set hz 20 # 提高為每秒20次
策略類型 | 觸發條件 | 優點 | 缺點 |
---|---|---|---|
被動刪除 | 鍵被訪問時 | CPU友好 | 內存回收不及時 |
主動刪除 | 定時任務觸發 | 平衡內存和CPU | 短時間可能占用高CPU |
假設一個電商平臺使用Redis緩存商品信息:
- 熱門商品(如iPhone)設置為永久鍵
- 促銷商品(如限時折扣)設置TTL=3600秒
- 內存限制2GB,策略為volatile-lru
# 查看過期鍵數量
127.0.0.1:6379> info stats | grep expired_keys
expired_keys:327
# 查看淘汰鍵數量
127.0.0.1:6379> info stats | grep evicted_keys
evicted_keys:42
activedefrag yes
自動整理碎片jemalloc
替代默認內存分配器LFU策略:allkeys-lfu
和volatile-lfu
基于訪問頻率淘汰
# 配置為LFU模式
config set maxmemory-policy allkeys-lfu
allkeys-lru
或allkeys-lfu
volatile-*
策略used_memory
:當前內存使用量keyspace_hits/misses
:淘汰策略有效性通過合理配置,Redis可在內存限制下保持高性能。建議通過
redis-benchmark
測試不同策略的吞吐量差異。
”`
注:本文示例基于Redis 7.0版本,部分命令在不同版本中可能存在差異。實際生產環境應結合監控數據持續優化策略參數。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。