摘要：如何定位分布式緩存數據庫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問題，實操案例帶你掌握優化方法。
【背景】
訪問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問題，盡早識別風險。
點擊關注，第一時間了解華為雲新鮮技術~