前言

Redis 應該是開發者最常用的緩存服務器了，它豐富的數據結構，快速高效的內存操作能幫助開發者迅速完成復雜功能的設計，可以說讓人一旦使用過後很難再離開它了，甚至在一些業務中，完全可以用 Redis 替代傳統的關系型數據庫 Mysql。

作為一個內存型數據庫，Redis 經常會遇到內存問題，今天我們來談一下 Redis 常見的內存滿的問題，介紹一下給 Redis “瘦身”的通用方式。

文章經常被人爬，而且還不註明原地址，我在這裏的更新和糾錯沒法同步，這裏註明一下原文地址：http://www.cnblogs.com/zhenbianshu/p/7642682.html 以防誤人子弟。

Redis內存回收

Redis 服務器的最大占用內存量由配置項 maxmemory 決定，我們可以通過 config set maxmemory 2GB 的格式來配置。一旦 Redis 內存滿，所有引起內存增加的操作都會被返回 error。作為專業 Redis 服務器我們通常將此項設置為0，以服務器系統內存來作為限制；

那麽 Redis 使用內存達到了上限怎麽辦？Redis 為我們提供了幾種選項以自動回收內存，可以通過配置項 maxmemory-policy 來配置；

• noeviction 不回收；
• allkeys-lru 從所有鍵中刪除最近最少使用的鍵；
• volatile-lru
  從設置了過期時間的鍵中刪除最近最少使用的鍵；
• allkeys-random 從所有鍵中隨機刪除；
• volatile-random 從設置了過期時間的鍵中隨機刪除；
• volatile-ttl 從設置了過期時間的鍵中選擇存活時間最短的鍵刪除；

最大內存回收策略需要根據業務來配置，如果純粹做緩存，allkeys-lru無疑是最合適的。如果存儲了稍微重要的數據，為了防止 Redis 誤刪一些重要鍵，則需要選用 noeviction；

allkeys-lru、allkeys-random 在內存滿時都有鍵可刪，可以騰出內存，但如果配置了其他的策略，數據庫用久了（根據業務量），隨著業務發展和數據積累，通常會累積到到服務器內存占用率高，利用率低的情況，則可能會遇到內存占用滿的問題。

問題原由

產生問題的原因有：

持久鍵廢棄

這是導致此問題的最常見情況。

有時候是開發人員的鍋，開發不規範，未給有時效性的鍵設置過期時間，後續又不進行手動刪除，鍵就成為無人管的孤兒鍵了。

還可能是整個業務慢慢被廢棄，不知道哪一天起，業務整體已不再維護了，一批鍵自然也就沒用了。比這更嚴重的是，如果使用 List 傳遞數據，消費進程已被停止，但生產進程未同步停止，還在往 Redis 裏寫數據。

過期鍵未回收

這個原因首先要談到 Redis 的兩種過期鍵刪除策略：

• 惰性刪除：在讀取鍵時發現鍵已過期，則將其刪除。
• 定期刪除：Redis 會從所有設置了過期時間的鍵中選取 100 個，刪除已過期的鍵，如果已過期的鍵超過 25 個，則再次進行此操作。 此刪除操作由配置項 hz 決定，Redis 默認每秒進行 10 次；

如果我們產生過期鍵的速度很快，最多可導致 Redis 25% 的過期鍵沒有被及時刪除。

遍歷清除垃圾鍵

由上，明白了問題產生的原因，解決 Redis 內存滿的方法就明確了：清除這些垃圾鍵。 於是就面臨著兩個問題：

如何遍歷鍵

對於查找鍵，我們首先想到的是 KEYS，但 KEYS 的時間復雜度是O(n)，n 是 Redis 內鍵的總數，如果 Redis 內鍵很多還是會有性能問題，導致其他命令被阻塞的。

這裏介紹一個鍵遍歷命令： SCAN。

SCAN cursor：

0 => cursor, // cursor = 0 遍歷結束
1 => array(key1, key2...)

需要註意的是 SCAN 命令是在版本2.8.0 加入的，如果是之前的版本，可以考慮解析 Redis 的 RDB 文件來獲取所有的鍵。有坑，參見我之前的文章：擴充你的工具箱 - 大行文件的處理

如何判斷鍵是否垃圾

我們有三種異常鍵需要處理：

• 過期鍵：這些鍵會在被 SCAN 到時被自動刪除，不再考慮。如果是解析 RDB 文件獲取到的鍵，在查詢時也會被自動刪除；
• 長時間未讀寫的鍵，很可能是業務不再需要的鍵；
• 占用大量內存的鍵，有可能是在不停地寫，但未消費。

這裏介紹 Redis 的另一個命令 OBJECT，使用它可以從內部查看 key 對象的狀態。使用 OBJECT IDLETIME key 來獲取 key 的閑置時間，我們可以判斷 key 閑置時間大於一個時間段（根據業務自定）的為已廢棄。

此外還能使用 OBJECT REFCOUNT key獲取 key 引用所儲存的值的次數，OBJECT ENCODING key 獲取 key 儲存的值所使用的內部表示。

獲取鍵大小

而獲取 Redis 某鍵占用內存大小，則通過另一個命令 DEBUG OBJECT 來獲取，此命令會返回比OBJECT命令更詳細的內部數據。

DEBUG OBJECT test
Value at:0x7fb0ee16ebd0 refcount:1 encoding:embstr serializedlength:6 lru:12362780 lru_seconds_idle:4

結果包括內存地址、引用數、內部編碼表示、序列化後的長度、最近最少使用標識值，閑置時間，我們可以解析此結果串來獲取對應的數據。

需要註意，key 作為復合鍵擁有大量字段時使用 DEBUG 命令計算內存會使 Redis 阻塞較長時間，且 Redis 官方並不建議在客戶端使用此命令。

我們也可以先使用 TYPE key 獲取鍵的類型，再根據類型獲取其鍵的大小，如對字符串使用LEN，對 哈希表使用HLEN。

要註意在刪除特別大的復合鍵時，建議先逐步清空鍵內的字段，防止因字段過多，Redis 阻塞較長時間。

管道加速

Redis 支持 pipeline 管道技術，一次 請求/響應 服務器能實現處理並響應多個請求。這樣就可以將多個命令同時發送到服務器，不等待回復，直接在最後獲取多個結果。

PHP 中使用 MULTI(Redis::PIPELINE) 和 EXEC() 命令來實現管道；

腳本實現

下面是個簡單的腳本：

$redis = new Redis();
$redis->connect(‘127.0.0.1‘);
do {
    $keys = $redis->scan($cursor);

    $pipeline = $redis->multi(Redis::PIPELINE);
    foreach ($keys as $key) {
        $idle_time = $redis->object(‘idletime‘, $key);
        if ($idle_time > 180 * 24 * 3600) {
            $pipeline->del($key);
        }
        // todo 判斷類型進而判斷占用內存大小，再刪除
    }
    $pipeline->exec();
} while ($cursor != 0);

從根源避免問題

以上的腳本肯定也會在刪除鍵時影響 Redis 的效率，最好的情況還是從根源就避免此類情況，以下是一些建議：

• 規範化開發；

  首先是鍵命名要規範，讓人見名知義，這樣在人工排錯或刪除時也有判斷依據，然後最好有完善的 Redis 鍵文檔，以保證業務在很長時間，經手多人後也能資料可查。

• 使用 HashSet 替代 Key-Value；

  將業務中某一族的鍵以 HashSet 的方式存儲，以替代普通的 key-value 類型。不僅可以省去為每個鍵設置前綴以節約內存，也便於統一管理。

• 有時效性的鍵註意設置過期時間；

• 合理設置定時清除過期鍵頻率 hz，在 Redis 不做多余操作的情況下，使過期鍵盡量能被刪除；

• 做好 Redis 內存的監控，在達到某個閾值時查找問題並解決。

小結

最後多絮叨兩句經驗：

Redis假死

我在使用守護進程時 Redis 有假死情況，PHP 和 Redis 都不報錯，但命令都返回 false，這種情況可以使用 Redis 的 ping() 命令，來探測 Redis 連接是否還在，如果不在則再建立新的連接。此問題很可能是由服務器配置引起的，如果您有知道此問題的原由或有好的解決辦法，煩請指點一二。

危險命令

不要在沒看文檔的情況下在線上使用 Redis 命令，例如 debug segfault，別問我怎麽知道的。

嗯，希望大家都能處理好跟 Redis 這個好朋友的關系。

關於本文有什麽問題可以在下面留言交流，如果您覺得本文對您有幫助，可以點擊下面的 推薦 支持一下我。博客一直在更新，歡迎 關註 。

Redis “瘦身”指南