你怎麼看redis的這些記憶體消耗資料，主要看哪乙個說明記憶體比較大

首先需要了解Redis是乙個資料庫 Redis是乙個記憶體資料庫，所有資料基本都存在於記憶體中，並且會以追加或快照的形式定期重新整理到硬碟中。 由於Redis是記憶體資料庫，讀寫速度非常快，因此常用於快取資料、頁面等。

如今，它被用於越來越多的系統中redis作為乙個快取系統，但隨著使用者數量的增長，業務資料不斷增加，Redis伺服器的記憶體空間可能會達到瓶頸，及時觀察Redis中各種key占用了多少記憶體，這將方便我們評估何時公升級Redis伺服器規格， 以及是否有必要優化方案來設計合理的儲存結構，下面就給大家介紹兩個工具rdr跟redis-rdb-tools，可以很好地滿足我們的需求。

1.首先，我必須去Redis伺服器端將RDB檔案複製到本地，為了方便起見，我將RDB檔案放在RDR工具所在的目錄下。

在這裡，我們通過檢視 Redis 伺服器配置檔案來討論如何找到 Redis RDB 檔案您可以快速找到配置，並按照路徑查詢 Redis RDB 備份檔案。

2.在 RDR 工具所在的路徑中開啟命令列視窗並執行該命令。

執行命令後，伺服器在本地啟動，並監聽埠 8080

3.開啟瀏覽器，訪問 http： localhost：8080 檢視詳細的記憶體使用資料報告，包括鍵數、不同資料型別、元素計數等。

但是通過網頁版的資料上報存在乙個小問題，Redis中不同資料庫之間沒有明顯的區別，混在一起，不太清楚。

有關更多資訊，請參閱官方儲存庫。

1.安裝python環境，我在這裡安裝。

2.通過 pip 安裝 redis-rdb-tools

這裡沒有安裝python-lzf庫，但是不影響實際使用，這個庫是為了加快RDB檔案解析速度

3.安裝完成後，可以在命令列中使用，輸入指令用於生成記憶體報告檔案。

等待一段時間後，執行命令阻塞後，會在 -f 引數指定的路徑中生成相應的檔案。

在Excel中開啟生成的CSV檔案，檢視詳細的統計結果，包括所有資料庫中所有鍵的記憶體使用情況

redis-rdb-tools 還自帶了乙個非常有用的命令，可以幫助我們直接查詢單個鍵的記憶體使用情況，格式如下。

命令執行後，直接顯示指定鍵對應的記憶體使用量。

需要注意的是，在生產環境中要謹慎使用此操作，根據金鑰的大小，執行可能會長時間受阻，並且可能會計算結果

客戶端通過 redis-cli 連線伺服器後，輸入 info memory

該命令將展示 Redis 系統關於儲存的統計資料，本文重點對 used memory、used memory RSS 和 MEM 碎片率這三個術語進行詳細解釋，歡迎大家批評和討論。

已用記憶體由 Redis 記憶體分配器（例如 jemalloc）分配。記憶體總量，主要用於儲存 Redis 實際執行時產生的資料。 請注意，此處提到的記憶體總量包括記憶跟虛擬記憶體

已用記憶體 RSS 是 Redis 程序在作業系統中占用的記憶體，因此除了分配器分配的記憶體外，還包括程序本身執行所需的記憶體、記憶體碎片等，但是不包括虛擬記憶體

從已用記憶體和已用記憶體rss的描述中，很難確定它們之間哪個大或小，原因如下：

1.如果使用的記憶體使用虛擬記憶體，則虛擬記憶體使用量超過Redis 程序本身占用大量記憶體程式記憶體碎片，則“已用記憶體”值可能大於“已用記憶體 RSS”。

如果使用的記憶體沒有被占用或占用了少量的虛擬記憶體，則使用的記憶體 RSS 值可能大於已使用的記憶體，這與上一篇文章相反。

兩者之間的關係可以從側面反映 Redis 系統的執行狀態，從而得出第三項，MEM 碎裂比。

MEM 碎片比率是已用記憶體與已用記憶體 RSS 已用記憶體的比率。 根據前面對使用記憶體 rss 和使用記憶體的含義的描述，很容易得出以下結論：

使用 redis-cli 登入 Redis 伺服器，執行 info 命令，其中'# memory'段落部分是 Redis 記憶體的用法，例如：

這是在配置檔案中：

Redis 支援執行時間，通過命令動態修改記憶體大小。

由於您可以設定 Redis 的最大記憶體大小，因此配置的記憶體會用完一段時間。 當記憶體耗盡時，是不是意味著繼續向 Redis 新增資料就沒有可用的記憶體了嗎？

事實上，Redis 定義了幾種策略來應對這種情況：

乙個寫在配置檔案中， ：

另一種是使用命令。

如上所述，Redis 可用的最大記憶體已經用完，可以使用 LRU 演算法來消除記憶體，那麼 LRU 演算法是什麼？

近似 LRU 演算法

Redis 使用近似 LRU 演算法，這與常規 LRU 演算法並不完全相同。 近似 LRU 演算法使用隨機抽樣方法消除資料，每次隨機選擇 5 個（預設）金鑰，並消除最近使用最少的金鑰。

為了實現近似 LRU 演算法，Redis 為每個金鑰新增了乙個額外的 24 位欄位，用於儲存上次訪問金鑰的時間。

近似 LRU 的優化

對近似 LRU 演算法進行了一些優化。 新演算法維護乙個候選池（大小 16），根據訪問時間對池中的資料進行排序，第乙個隨機選擇的金鑰會放入池中，後續每個隨機鍵只有在訪問時間小於池中的最小時間時才會放入池中， 直到候選人庫已滿。當它已滿時，如果需要新增新金鑰，則池中的上次訪問時間（最近一次訪問）將被刪除。

當需要消除金鑰時，可以直接從池中選擇最近訪問時間最短（最長時間不訪問時間）的金鑰並消除。

LFU演算法是一種新的消除策略。 它的全名使用頻率最低，其核心思想是消除金鑰最近訪問的頻率，最少訪問的優先消除，訪問最多的保留。

LFU 演算法可以更好地表示正在訪問的金鑰的受歡迎程度。 如果你使用的是 LRU 演算法，並且乙個金鑰已經很久沒有被訪問了，只是偶爾訪問一次，那麼它就被認為是熱資料，不會被淘汰，並且一些未來可能會被訪問的金鑰會被淘汰。 如果使用 LFU 演算法，則情況並非如此，因為使用一次不會成為關鍵熱點。

LFU 有兩種策略：