使用Redis作為LRU快取

當 redis 作為快取使用時，當你新增新的資料時，有時候很方便使 redis 自動**老的資料。lru 實際上是被唯一支援的資料移除方法。redis 的 maxmemory 指令，用於限制記憶體使用到乙個固定的容量，也包含深入** redis 使用的 lru 演算法，乙個近似準確的 lru。

maxmemory 配置指令是用來配置 redis 為資料集使用指定的記憶體容量大小。可以使用 redis.conf 檔案來設定配置指令，或者之後在執行時使用 config set 命令。

例如，為了配置記憶體限制為 100mb，可以在 redis.conf 檔案中使用以下指令

maxmemory 100mb

設定 maxmemory 為 0，表示沒有記憶體限制。這是 64 位系統的預設行為，32 位的系統則使用 3g 大小作為隱式的記憶體限制。

當指定的記憶體容量到達時，需要選擇不同的行為，即策略。redis 可以只為命令返回錯誤，這樣將占用更多的記憶體，或者每次新增新資料時，**掉一些舊的資料以避免記憶體限制。

當 maxmemory 限制到達的時候，redis 將採取的準確行為是由 maxmemory-policy 配置指令配置的。

以下策略可用：

當沒有滿足前提條件的話，volatile-lru，volatile-random 和 volatile-ttl 策略就表現得和 noeviction 一樣了。

選擇正確的**策略是很重要的，取決於你的應用程式的訪問模式，但是，你可以在程式執行時重新配置策略，使用 info 輸出來監控快取命中和錯過的次數，以調優你的設定。

一般經驗規則：

當你想使用單個例項來實現快取和持久化一些鍵，allkeys-lru 和 volatile-random 策略會很有用。但是，通常最好是執行兩個 redis 例項來解決這個問題。

另外值得注意的是，為鍵設定過期時間需要消耗記憶體，所以使用像 allkeys-lru 這樣的策略會更高效，因為在記憶體壓力下沒有必要為鍵的**設定過期時間。

理解**的過程是這麼運作的非常的重要：

通過檢查，然後**鍵以返回到限制以下，來連續不斷的穿越記憶體限制的邊界。

如果乙個命令導致大量的記憶體被占用 (像乙個很大的集合交集儲存到乙個新的鍵)，一會功夫記憶體限制就會被這個明顯的記憶體量所超越。

redis 的 lru 演算法不是乙個精確的實現。這意味著 redis 不能選擇最佳候選鍵來**，也就是最久錢被訪問的那些鍵。相反，會嘗試運營乙個近似的 lru 演算法，通過取樣一小部分鍵，然後在取樣鍵中**最適合(擁有最久訪問時間)的那個。

redis 的 lru 演算法有一點很重要，你可以調整演算法的精度，通過改變每次**時檢查的取樣數量。這個引數可以通過如下配置指令

maxmemory-samples 5

redis 沒有使用真實的 lru 實現的原因，是因為這會消耗更多的記憶體。然而，近似值對使用 redis 的應用來說基本上也是等價的。為 redis 使用的 lru 近似值和真實 lru 之間的比較。

redis 服務被填充了指定數量的鍵。鍵被從頭訪問到尾，所以第乙個鍵是 lru 演算法的最佳候選**鍵。然後，再新新增 50% 的鍵，強制一般的舊鍵被**。

在理論的 lru 實現中，我們期待看到的是，在舊鍵中第一半會過期。而 redis 的 lru 演算法則只是概率性的過期這些舊鍵。

你可以看到，同樣採用 5 個取樣，redis 3.0 表現得比 redis 2.8 要好，redis 2.8 中最近被訪問的物件之間的物件仍然被保留。在 redis 3.0 中使用 10 為取樣大小，近似值已經非常接近理論效能。

注意，lru 只是乙個預言指定鍵在未來如何被訪問的模式。另外，如果你的資料訪問模式非常接近冪律，大多數的訪問都將集中在乙個集合中，lru 近似演算法將能處理得很好。

在模擬實驗的過程中，我們發現使用冪律訪問模式，真實的 lru 演算法和 redis 的近似演算法之間的差異非常小，或者根本就沒有。

然而，你可以提高取樣大小到 10，這會消耗額外的 cpu，來更加近似於真實的 lru 演算法，看看這會不會使你的快取錯失率有差異。

使用 config set maxmemory-samples 命令在生產環境上試驗各種不同的取樣大小值是很簡單的。