Redis的怎么清理沒用的數據

本篇內容主要講解“Redis的怎么清理沒用的數據”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Redis的怎么清理沒用的數據”吧!

我們數據平臺中有使用Redis來給線上提供低延時(20毫秒以內)的高并發讀寫請求，其中***的Redis使用了阿里云的Redis集群(256G)，存儲的記錄超過10億，Key的有效期設置為15天，每天寫入的記錄大概5000萬左右，QPS大概在6萬左右。由于過期Key的產生速度大于Redis自動清理的速度，因此在Redis中會有大量過期Key未被及時清理。

為什么有過期的Key未被清理呢?這個得先熟悉一下Redis的刪除策略。

Redis常用的刪除策略有以下三種：

• 被動刪除(惰性刪除)：當讀/寫一個已經過期的Key時，會觸發惰性刪除策略，直接刪除掉這個Key;

• 主動刪除(定期刪除)：Redis會定期巡檢，來清理過期Key;

• 當內存達到maxmemory配置時候，會觸發Key的刪除操作;

另外，還有一種基于觸發器的刪除策略，因為對Redis壓力太大，一般沒人使用。

這里先介紹后兩種刪除策略(網上有很多說明)。

主動刪除(定期刪除)

在 Redis 中，常規操作由 redis.c/serverCron 實現，它主要執行以下操作：

• 更新服務器的各類統計信息，比如時間、內存占用、數據庫占用情況等。

• 清理數據庫中的過期鍵值對。

• 對不合理的數據庫進行大小調整。

• 關閉和清理連接失效的客戶端。

• 嘗試進行 AOF 或 RDB 持久化操作。

• 如果服務器是主節點的話，對附屬節點進行定期同步。

• 如果處于集群模式的話，對集群進行定期同步和連接測試。

Redis 將 serverCron 作為時間事件來運行，從而確保它每隔一段時間就會自動運行一次， 又因為 serverCron 需要在 Redis  服務器運行期間一直定期運行， 所以它是一個循環時間事件：serverCron 會一直定期執行，直到服務器關閉為止。

在 Redis 2.6 版本中， 程序規定 serverCron 每秒運行 10 次， 平均每 100 毫秒運行一次。 從 Redis 2.8 開始，  用戶可以通過修改 hz選項來調整 serverCron 的每秒執行次數， 具體信息請參考 redis.conf 文件中關于 hz 選項的說明。

也叫定時刪除，這里的“定期”指的是Redis定期觸發的清理策略，由位于src/redis.c的activeExpireCycle(void)函數來完成。

serverCron是由redis的事件框架驅動的定位任務，這個定時任務中會調用activeExpireCycle函數，針對每個db在限制的時間REDIS_EXPIRELOOKUPS_TIME_LIMIT內遲可能多的刪除過期key，之所以要限制時間是為了防止過長時間  的阻塞影響redis的正常運行。這種主動刪除策略彌補了被動刪除策略在內存上的不友好。

因此，Redis會周期性的隨機測試一批設置了過期時間的key并進行處理。測試到的已過期的key將被刪除。典型的方式為,Redis每秒做10次如下的步驟：

• 隨機測試100個設置了過期時間的key

• 刪除所有發現的已過期的key

• 若刪除的key超過25個則重復步驟1

這是一個基于概率的簡單算法，基本的假設是抽出的樣本能夠代表整個key空間，redis持續清理過期的數據直至將要過期的key的百分比降到了25%以下。這也意味著在任何給定的時刻已經過期但仍占據著內存空間的key的量最多為每秒的寫操作量除以4.

Redis-3.0.0中的默認值是10，代表每秒鐘調用10次后臺任務。

除了主動淘汰的頻率外，Redis對每次淘汰任務執行的***時長也有一個限定，這樣保證了每次主動淘汰不會過多阻塞應用請求，以下是這個限定計算公式：

#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* CPU max % for keys collection */  …  timelimit = 1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/server.hz/100;

hz調大將會提高Redis主動淘汰的頻率，如果你的Redis存儲中包含很多冷數據占用內存過大的話，可以考慮將這個值調大，但Redis作者建議這個值不要超過100。我們實際線上將這個值調大到100，觀察到CPU會增加2%左右，但對冷數據的內存釋放速度確實有明顯的提高(通過觀察keyspace個數和used_memory大小)。

可以看出timelimit和server.hz是一個倒數的關系，也就是說hz配置越大，timelimit就越小。換句話說是每秒鐘期望的主動淘汰頻率越高，則每次淘汰最長占用時間就越短。這里每秒鐘的最長淘汰占用時間是固定的250ms(1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/100)，而淘汰頻率和每次淘汰的最長時間是通過hz參數控制的。

從以上的分析看，當redis中的過期key比率沒有超過25%之前，提高hz可以明顯提高掃描key的最小個數。假設hz為10，則一秒內最少掃描200個key(一秒調用10次*每次最少隨機取出20個key)，如果hz改為100，則一秒內最少掃描2000個key;另一方面，如果過期key比率超過25%，則掃描key的個數無上限，但是cpu時間每秒鐘最多占用250ms。

當REDIS運行在主從模式時，只有主結點才會執行上述這兩種過期刪除策略，然后把刪除操作”del key”同步到從結點。

maxmemory

當前已用內存超過maxmemory限定時，觸發主動清理策略，這些策略可以配置(參數maxmemory-policy)，包括以下幾個：

volatile-lru：從已設置過期時間的數據集(server.db[i].expires)中挑選最近最少使用的數據淘汰

volatile-ttl：從已設置過期時間的數據集(server.db[i].expires)中挑選將要過期的數據淘汰

volatile-random：從已設置過期時間的數據集(server.db[i].expires)中任意選擇數據淘汰

allkeys-lru：從數據集(server.db[i].dict)中挑選最近最少使用的數據淘汰

allkeys-random：從數據集(server.db[i].dict)中任意選擇數據淘汰

no-enviction(驅逐)：禁止驅逐數據

當mem_used內存已經超過maxmemory的設定，對于所有的讀寫請求，都會觸發redis.c/freeMemoryIfNeeded(void)函數以清理超出的內存。注意這個清理過程是阻塞的，直到清理出足夠的內存空間。所以如果在達到maxmemory并且調用方還在不斷寫入的情況下，可能會反復觸發主動清理策略，導致請求會有一定的延遲。

清理時會根據用戶配置的maxmemory-policy來做適當的清理(一般是LRU或TTL)，這里的LRU或TTL策略并不是針對redis的所有key，而是以配置文件中的maxmemory-samples個key作為樣本池進行抽樣清理。

總結與備忘

如果Redis中每天過期大量Key(比如幾千萬)，那么必須得考慮過期Key的清理：

增加Redis主動清理的頻率(通過調大hz參數);

手動清理過期Key，最簡單的方法是進行scan操作，scan操作會觸發***種被動刪除，scan操作時候別忘了加count;

dbsize命令返回的Key數量，包含了過期Key;

randomkey命令返回的Key，不包含過期Key;

scan命令返回的Key，包含過期Key;

info命令返回的# Keyspace：

db6:keys=1034937352,expires=994731489,avg_ttl=507838502

keys對應的Key數量等同于dbsize;

expires指的是設置了過期時間的Key數量;

avg_ttl指設置了過期時間的Key的平均過期時間(單位：毫秒);

到此，相信大家對“Redis的怎么清理沒用的數據”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！