HI! 我是小小，今天是本周的第六篇，本篇將會著重講解關於Redis負載的問題。
網頁監控
通過阿里的Grafana監控，發現伺服器的CPU負載，內存，網絡輸入輸出相當正常，所以Redis出現問題。使用單節點的32M 16GB的阿里雲Redis，登錄網頁，查看性能監控，發現CPU使用飆升到100%；
QPS從1000升高到6000，但是遠遠低於極限值，連接數量從0升高到3000，也就是遠遠低於極限值。臨時方案：先短期租用一臺Redis，臨時更換Redis配置，重啟應用。儘快排查
伺服器命令監控
登錄Redis-cli，通過info命令查看伺服器狀態和命令統計，總結異常點：
查詢Reduis慢指令slowlog，以及keys_並且耗費時間嚴重，在當前業務下執行keys_會導致阻塞業務，導致查詢國漫，cpu過稿。
查看redis指令執行情況，排除exec，flushall指令，業務使用指令過程中耗時嚴重的有setnx有7.5千萬次調用平均耗時6s，setex有8.4萬次調用平均耗時7.33s，del有2.6億吃調研耗時69s，hegtall有14億次調用耗時20s，keys有2千萬次調用平均耗時 3740s。通常而言，這些指令耗時與 value 大小呈正比，所以可以排查這些指令相關的數據近期有沒有較大增長。或者近期有沒有業務改造，會頻繁使用上述指令，也會造成 cpu 高。
通過 info commandstats 可以查看 Redis 命令統計信息，其中命令格式是
調用次數、耗費CPU時間、每個命令平均耗費CPU(單位為微秒）
通過 slowlog 命令查看慢命令（默認超過 10ms 就會被記錄到日誌，只會記錄其命令執行的時間，不包含 IO 往返操作，也不記錄單由網絡延遲引起的響應慢）slowlog命令格式如下
圖中各欄位表示的是：
1=日誌的唯一標識符
2=命令的執行時間點，以UNIX時間戳表示
3=查詢命令執行時間，以微妙為單位，中的是230ms
4=執行的命令，以數組的形式排列。完整的命令是 keys mucury:*所以通過這些參數，基本可以確定，是突然有大量的keys *命令導致CPU負載升高，導致響應延遲，問題我們應用中沒有開放keys *命令問題解決
關於作者
我是小小，雙魚座的程序猿，我麼下期再見~bye
END
「 往期文章 」