分布式緩存數據庫Redis大KEY問題定位及優化建議是怎樣的

這篇文章給大家介紹分布式緩存數據庫Redis大KEY問題定位及優化建議是怎樣的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

如何定位分布式緩存數據庫Redis大KEY問題，實操案例帶你掌握優化方法。

【背景】

訪問Redis 5.0 cluster集群出現OOM報錯，報錯信息為（error） OOM command not allowed when used memory > ‘maxmemory’,部分ECS應用程序無法向數據庫寫入，影響服務的正常使用。執行set t2 s2時，數據庫報錯OOM，如下圖：

【拓撲】

環境信息：

Redis 5.0 cluster集群 4G內存

DCS網段：192.168.1.0/24

分片1：master 192.168.1.12 slave 192.168.1.37

分片2：master 192.168.1.10 slave 192.168.1.69

分片3：master 192.168.1.26 slave 192.168.1.134

【分析思路】

【詳細步驟】

一、查看監控

查看Redis實例監控，顯示Redis集群內存占用46.97%，無明顯異常，結果如下圖所示：

查看節點的內存監控。其中分片2中master節點192.168.1.10內存使用率達到100%，其余兩個分片分內存使用率均在20%左右，結果如下圖所示：

二、確認異常分片信息

通過上述監控信息可得知，該redis集群中的分片2中內存使用率達100%。有且僅有該分片內存異常。

三、大KEY分析

在線分析

① 工具分析：使用華為云管理控制臺緩存分析-大Key分析工具。執行完成后，查看信息即可。結果如下圖所示：（string類型保存top20，list/set/zset/hash類型保存top80）

具體使用方法參考以下鏈接：https://support.huaweicloud.com/usermanual-dcs/dcs-ug-190808001.html

② 命令分析：使用redis-cli -h IP -p port –bigkeys命令，該工具會列出各個類型數據中大Key中的最大的那個key的信息。結果如下圖所示：

如上圖所示，可以得出該環境中string類型的大key為“nc_filed/_pk”,大小為13283byte，list、set、hash、zset類型的數據未發現大key。

離線方式

離線分析需要使用專門的rdb_bigkeys分析工具，對rdb文件進行分析。工具地址： https://github.com/weiyanwei412/rdb_bigkeys。具體步驟如下：

編譯方法：

# yum install git go -y

# mkdir /home/gocode/

# cd /home/gocode/

# git clone https://github.com/weiyanwei412/rdb_bigkeys.git

# cd rdb_bigkeys

# go build

執行完成生成可執行文件rdb_bigkeys。
使用方法：

./rdb_bigkeys -bytes 1024 -file bigkeys.csv -sorted -threads 4 /home/redis/dump.rdb

參數說明：

-bytes 1024：篩選大于1024字節的key

-file bigkeys.csv：將結果保存到bigkeys.csv文件

-sorted：從大到小進行排序

-threads：使用的線程個數

/home/redis/dump.rdb：實際的rdb文件路徑

生成文件樣式如下所示：

每列分別為數據庫編號，key類型，key名，key大小，元素數量，最大值元素名，元素大小，key過期時間。文檔鏈接：https://www.cnblogs.com/yqzc/p/12425533.html

四、解決方案

導致本次OOM問題的根因為大KEY導致數據大小分布不均勻，某一個分片內存達到maxmemory，在進行數據寫入的過程中，如果調度到該分片，則會產生OOM問題。將該分片的rdb文件導出一份，以便于后期針對大key做對應的優化。

臨時方案：

為盡快回復業務，刪除上有步驟中查詢到的大KEY，執行操作如下：(非字符串的bigkey，不要使用 del 刪除，使用 hscan、sscan、zscan 方式漸進式刪除）

長期方案：

通過對大KEY進行拆分，將一個大的KEY拆分為多個小的KEY, 變成value1，value2… valueN，打散分不到不同的分片中，避免因為數據傾斜導致的數據分布不均。

其他的類型的數據也可以按照相同的方式進行拆分重組，從而避免大KEY帶來的影響。

五、 結果驗證

查看分片監控，192.168.1.10內存使用率下降到24%，結果如下圖所示：

執行set t2 s2，返回正常，登錄集群，執行get命令，正常返回數據信息。結果如下所示，至此業務恢復正常。

【優化及建議】

1) 配置節點級別的內存利用率監控指標的告警。如果某個節點存在大key，這個節點比其他節點內存使用率高很多，會觸發告警，便于用戶發現潛在的大key。

2) 配置節點級別的入網最大帶寬、出網最大帶寬、CPU利用率監控指標的告警。如果某個節點存在熱key，這個節點的帶寬占用、CPU利用率都比其他節點高，該節點會容易觸發告警，便于用戶發現潛在熱key。

3) string類型控制在10KB以內，hash、list、set、zset元素盡量不超過5000。

4) 定期通過大key、熱key分析工具檢查集群中是否存在大key問題，盡早識別風險。

關于分布式緩存數據庫Redis大KEY問題定位及優化建議是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。