Redis 高負(fù)載排查記錄
來(lái)源：https://www.sevenyuan.cn/
網(wǎng)頁(yè)監(jiān)控
通過(guò)阿里的 Grafana 監(jiān)控，服務(wù)器的 CPU 負(fù)載、內(nèi)存、網(wǎng)絡(luò)輸入輸出都挺正常的，所以肯定是 Redis 出現(xiàn)了問(wèn)題。
我們應(yīng)用使用的是單節(jié)點(diǎn)的 32M 16GB 的阿里云 Redis，登錄網(wǎng)頁(yè)監(jiān)控看性能監(jiān)控，發(fā)現(xiàn) CPU 使用情況飆升到100%！！！
QPS 雖然從 1000 多升到 6000，但是遠(yuǎn)遠(yuǎn)低于極限值，連接數(shù)量從 0 升到 3000，也是遠(yuǎn)遠(yuǎn)低于極限值（可能用戶剛上班，開(kāi)始有請(qǐng)求，然后響應(yīng)延遲，導(dǎo)致命令隊(duì)列數(shù)量過(guò)多，打開(kāi)很多連接）。
臨時(shí)方案：先租用一臺(tái)新的 Redis 服務(wù)器，更換應(yīng)用服務(wù)器的 Redis 配置，重啟應(yīng)用，避免影響更多用戶。
然后我們繼續(xù)跟蹤 Redis 的具體情況。
服務(wù)器命令監(jiān)控
登錄 Redis-cli，通過(guò) info 命令查看服務(wù)器狀態(tài)和命令統(tǒng)計(jì)，祥哥總結(jié)了兩點(diǎn)異常點(diǎn)：
查詢 redis 慢指令 slowlog，排行前十的指令均為keys *，并且耗時(shí)嚴(yán)重，在當(dāng)前業(yè)務(wù)流量下執(zhí)行keys* ，一定會(huì)阻塞業(yè)務(wù)，導(dǎo)致查詢慢，cpu 高的。值得注意的是應(yīng)用層面沒(méi)有開(kāi)放 keys * 接口，不排查有后臺(tái)人為或后臺(tái)程序觸發(fā)該指令。
查看 redis 指令執(zhí)行情況，排除 exec,flushall 等指令，業(yè)務(wù)使用指令中，耗時(shí)嚴(yán)重的有 setnx 有7.5千萬(wàn)次調(diào)用平均耗時(shí) 6s，setex 有8.4千萬(wàn)次調(diào)用平均耗時(shí)7.33s，del 有2.6億次調(diào)用平均耗時(shí)69s，hmset 有1億次調(diào)用平均耗時(shí) 64s，hmget 有6.8千萬(wàn)次調(diào)用平均耗時(shí) 9s，hgetall 有14億次調(diào)用平均耗時(shí) 205s，keys 有2千萬(wàn)次調(diào)用平均耗時(shí) 3740s。
通常而言，這些指令耗時(shí)與 value 大小呈正比，所以可以排查這些指令相關(guān)的數(shù)據(jù)近期有沒(méi)有較大增長(zhǎng)。或者近期有沒(méi)有業(yè)務(wù)改造，會(huì)頻繁使用上述指令，也會(huì)造成 cpu 高。
（當(dāng)時(shí)忘了截圖，下圖只是展示命令和參數(shù)含義）
通過(guò) info commandstats 可以查看 Redis 命令統(tǒng)計(jì)信息，其中命令格式是
cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX
調(diào)用次數(shù)、耗費(fèi)CPU時(shí)間、每個(gè)命令平均耗費(fèi)CPU(單位為微秒）
通過(guò) slowlog 命令查看慢命令（默認(rèn)超過(guò) 10ms 就會(huì)被記錄到日志，只會(huì)記錄其命令執(zhí)行的時(shí)間，不包含 IO 往返操作，也不記錄單由網(wǎng)絡(luò)延遲引起的響應(yīng)慢）
(當(dāng)時(shí)也忘了截圖，所以就介紹一下 slowlog 怎么看）
xxxxx> slowlog get 10
3) 1) (integer) 411
2) (integer) 1545386469
3) (integer) 232663
4) 1) "keys"
2) "mecury:*"
圖中各字段表示的是：
1=日志的唯一標(biāo)識(shí)符 2=命令的執(zhí)行時(shí)間點(diǎn)，以UNIX時(shí)間戳表示 3=查詢命令執(zhí)行時(shí)間，以微妙為單位，??中的是230ms 4=執(zhí)行的命令，以數(shù)組的形式排列。完整的命令是 keys mucury:*
所以通過(guò)這些參數(shù)，基本可以確定，是突然有大量的keys *命令導(dǎo)致CPU負(fù)載升高，導(dǎo)致響應(yīng)延遲，問(wèn)題我們應(yīng)用中沒(méi)有開(kāi)放keys *命令Σ(o?д?o?)
最后將這些統(tǒng)計(jì)結(jié)果和慢命令發(fā)到研發(fā)群，發(fā)現(xiàn)是別的應(yīng)用配置配成了我們的Redis，然后他們有個(gè)業(yè)務(wù)場(chǎng)景是爬數(shù)據(jù)，突然涌入大量的調(diào)用，不斷的keys *，導(dǎo)致我們的Redis不堪重負(fù)，于是將配置修改正確，不再調(diào)用我們的Redis。
總結(jié)
Redis 抖動(dòng)可以先看網(wǎng)頁(yè)監(jiān)控（阿里云做的真好！） 通過(guò)命令查看 Redis 指令狀態(tài)和慢命令的情況 考慮優(yōu)化 Redis 在代碼中的使用情況 如果流量繼續(xù)上升，需要考慮一下升級(jí)了=-=
- END -
推薦閱讀 企業(yè)落地 Kubernetes 的核心技術(shù)方案 圖解 Kafka ZooKeeper、Eureka、Consul、Nacos 微服務(wù)注冊(cè)中心對(duì)比 Docker鏡像優(yōu)化：從1.16GB到22.4MB 這個(gè)程序占用CPU特別高！秒級(jí)定位線上問(wèn)題 從零開(kāi)始搭建創(chuàng)業(yè)公司DevOps技術(shù)棧 Shell 腳本進(jìn)階，經(jīng)典用法及其案例 2021年的DevOps趨勢(shì)預(yù)測(cè) Kubernetes+Helm+Jenkins 自動(dòng)化發(fā)布項(xiàng)目 搭建一套完整的企業(yè)級(jí) K8s 集群（v1.20，二進(jìn)制方式） 60道常見(jiàn)的 Kubernetes 面試題總結(jié)
點(diǎn)亮，服務(wù)器三年不宕機(jī)
