共計 2344 個字符，預計需要花費 6 分鐘才能閱讀完成。
這篇文章給大家介紹分布式緩存數據庫 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 問題定位及優化建議是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
