日常業務運行過程中，Redis 實例經常因各種 Big keys / Hot Keys 的問題未及時處理，導致服務性能下降、訪問超時、用戶體驗變差，甚至可能造成實例大范圍故障 。

這篇文章，我們聊聊生產環境，如何應對 Redis 大 Key 問題。

圖片

一、什么是大 key

大 Key 具體表現為 Redis 中的 Key 對應的 Value 很大，占用 Redis 空間比較大，本質上是大 Value 問題。

對于 Redis 中不同的數據結構類型，常見示例如下所示：

對于 String 類型的 Value 值，值超過 10MB（數據值太大）。

對于 Set 類型的 Value 值，含有的成員數量為 10000 個（成員數量多）。

對于 List 類型的 Value 值，含有的成員數量為 10000 個（成員數量多）。

對于 Hash 格式的 Value 值，含有的成員數量 1000 個，但所有成員變量的總 Value 值大小為 1000 MB（成員總的體積過大）。

在 Redis 的實際應用中，大 Key  問題的定義和評判標準并非固定不變，而是需要結合具體業務場景和性能需求進行綜合考量。

例如，在高并發、低延遲的敏感場景下，即使 10 KB  的數據也可能被視為大 Key；而在低并發、高吞吐量的離線處理環境中，大 Key 的閾值可能放寬至 100 KB 甚至更高。

因此，在 Redis  的設計和使用過程中，應該基于業務特性和性能指標來制定合理的大 Key 評估標準。

二、大 key 有什么影響

Redis 是單線程執行命令 ，當前面的任務完成不了，那后面的命令就會阻塞，從而導致如下的結果：

1.請求響應時間上升，超時阻塞。

Redis 是單線程架構，操作大 Key 耗時較長，可能造成請求阻塞。

2.同步中斷或主從切換

內存不足時，對大 Key 進行驅逐操作或者 rename 一個大 Key，容易長時間阻塞主庫，進而可能引發同步中斷或主從切換。

3.網絡擁塞

一個大 Key 占用空間是 1MB，每秒訪問1000 次，就有1000 MB 的流量，可能造成實例或局域網的帶寬被占滿，自身服務變慢，同時影響其他服務。

4.內存使用不均勻

在 Redis 集群架構中，某個數據分片的內存使用率遠超其他數據分片，內存資源無法達到均衡。另外，Redis 內存可能達到 maxmemory 參數定義的上限，導致重要的 Key 被逐出，甚至引發內存溢出。

需要強調的是：

對于 Java 應用來講，高并發場景 大 Key 問題容易導致應用服務器 CPU Load / 內存占用飆高。

圖片

如圖，這個一個非常標準的通過 redisTemplate 查詢用戶緩存信息的方法。

但當用戶 DTO 對象占用內存大小達到 300k ~ 500k 時，并發高情況下，海量 UserDTO 對象會在新生代產生，對象序列化 和 GC 線程會大量占用 CPU 資源，導致 CPU Load 飆高 ，最終應用線程大面積阻塞。

三、大 key 是如何產生的

1.錯誤的技術選型

比如使用 String 類型的 Key 存放大體積二進制文件型數據，從而造成 key 對應的 value 值特別大 ；

2.List 、Set 數據類型數據未清理

如圖，我們經常使用 Redis List 作為消息隊列，在實際使用中經常出現如下問題：生產者發送消息過快，但消費者消費消息速度低，導致數據堆積占用大量內存空間 。

3.數據沒有合理做分片

業務上線前，對業務分析不準確，沒有對 Key 中的成員進行合理的拆分，造成個別 Key 中的成員數量過多。

四、如何找到大 key

1.bigkeys 命令

執行 redis-cli 命令時帶上–bigkeys 選項，對整個數據庫中的鍵值對大小情況進行統計分析，統計每種數據類型的鍵值對個數以及平均大小。

此外，這個命令執行后，會輸出每種數據類型中最大的 bigkey 的信息：

• 對于 String 類型來說，會輸出最大 bigkey 的字節長度
• 對于集合類型來說，會輸出最大 bigkey 的元素個數

圖片

bigkeys 是通過掃描數據庫來查找的，在執行的過程中，會對 Redis 實例的性能產生影響。

• 主從集群，建議在從節點上執行該命令，避免阻塞主節點。
• 沒有從節點情況下，在 Redis 實例業務壓力的低峰階段進行掃描查詢，以免影響到實例的正常運行。

2.監控平臺

公有云或者公司內部架構部門一般都有監控平臺，可以可視化分析 Redis 服務監控指標。

如下圖是阿里云的 Redis 監控大 Key 分析界面 。

圖片

假如是架構部門自己的監控平臺，可以添加 Redis 的 Key 監控統計。

下圖是UMP 監控平臺的設計思路：

圖片

流程如下：

• 業務系統引入通 UMP SDK ，當業務系統運行時，SDK 會將日志文件（JVM、TP 、HeatBeat）寫到磁盤 ；
• FileBeat  讀取日志文件，發送到 Kafka ；
• UMP 計算服務 從 Kafka 中獲取消息，根據消息類型，執行分析邏輯（JVM、TP 、HeatBeat ）；
• 計算完成之后，指標結果數據存儲到 Hbase，MySQL 用于存儲元數據，Redis 用于存儲臨時計算數據 ；
• 研發人員登錄控制臺查看監控信息 ，核心的監控數據存儲在 Hbase 中，通過 HighChart 組件渲染。

UMP 可以對應用端的 Redis 操作實現全面的監控，包括命令超時、Key大小、使用頻率等關鍵指標。

五、如何解決大 key 問題

1.清理無效的數據

主要針對 list 和 set 這種類型，在使用的過程中，list 和 set 中對應的內容不斷增加，需要定時的對 list 和 set 進行清理。

2.壓縮對應的大 Key 的 Value

通過序列化或者壓縮的方法對 value 進行壓縮，使其變為較小的 value，但是如果壓縮之后如果對應的 value 還是特別大的話，就需要使用拆分的方法進行解決。

3.針對大 Key 進行拆分

通過將 BigKey 拆分成多個小 Key 的鍵值對，并且拆分后的對應的 value 大小和拆分成的成員數量比較合理，然后進行存儲即可，在獲取的時候通過 get 不同的 key 或是用 mget 批量獲取存儲的鍵值對。

4.實時監控 Redis 內存、帶寬及 Key 增長變化趨勢

通過監控系統，監控 Redis 中的內存占用大小和網絡帶寬的占用大小，以及固定時間內的內存占用增長率，當超過設定的閾值的時候，進行報警通知處理。