建站
咨詢
售后
建站咨詢
新聞中心
背景
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名注冊(cè)、虛擬空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、紅寺堡網(wǎng)站維護(hù)、網(wǎng)站推廣。
你好，我是彤哥。
昨天晚上下班回家，在地鐵上，老大突然打來(lái)電話，B系統(tǒng)生產(chǎn)環(huán)境響應(yīng)緩慢，影響了A系統(tǒng)的使用，幾萬(wàn)小哥收不了單，大概有30萬(wàn)單卡住了，你去幫忙定位一下。
我8點(diǎn)半左右到家，立馬上線入會(huì)。
重啟
我入會(huì)的時(shí)候，已經(jīng)有同事在幫忙定位了，俗話說(shuō)的好，重啟能解決80%的問(wèn)題，如果重啟解決不了，那肯定是重啟的次數(shù)還不夠，呸，不對(duì)，重啟解決不了，就真的要去定位了。
事實(shí)證明，重啟后走一波壓測(cè)依然沒(méi)什么用，1000個(gè)并發(fā)，平均響應(yīng)時(shí)間在3~4秒，連續(xù)壓了幾次都是這樣的結(jié)果。
升級(jí)配置
重啟看來(lái)是無(wú)效了，進(jìn)入第二個(gè)階段——升級(jí)配置，2臺(tái)4核8G的實(shí)例升級(jí)到6臺(tái)8核16G，數(shù)據(jù)庫(kù)的配置也翻了一倍，能用錢解決的問(wèn)題，我們一般不會(huì)投入太多的人力^^
事實(shí)證明，加配置也沒(méi)什么卵用，1000個(gè)并發(fā)，壓測(cè)的平均響應(yīng)時(shí)間還是在3~4秒。
有點(diǎn)意思了。
此時(shí)，彤哥我介入了。
查看監(jiān)控
我上線之后，查看了一下監(jiān)控，實(shí)例的CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)IO、JVM堆內(nèi)存使用情況好像都沒(méi)啥問(wèn)題，這真是個(gè)頭疼的問(wèn)題。
本地壓測(cè)
我們分成兩波同學(xué)，一波去準(zhǔn)備本地壓測(cè)，一波繼續(xù)分析，經(jīng)過(guò)本地壓測(cè)，我們發(fā)現(xiàn)，本地環(huán)境，單機(jī)，1000個(gè)并發(fā)，妥妥的，毛問(wèn)題都沒(méi)有，平均響應(yīng)基本維持在幾百毫秒。
看來(lái)，確實(shí)跟服務(wù)本身沒(méi)有問(wèn)題。
代碼走查
實(shí)在沒(méi)有辦法了，拿出代碼，一群大老爺們一起看代碼，研發(fā)同學(xué)給我們講解業(yè)務(wù)邏輯，當(dāng)然，他已經(jīng)被各位大佬給罵死了，寫(xiě)的什么破代碼，其實(shí)，在彤哥介入之前，他們已經(jīng)改過(guò)一波代碼了，有個(gè)地方把redis命令scan改成了keys *，這里埋了個(gè)坑，但是，現(xiàn)在不是主要問(wèn)題，后面我們會(huì)說(shuō)。
代碼一路走讀下來(lái)，發(fā)現(xiàn)有很多的redis操作，還有個(gè)for循環(huán)里面在調(diào)redis的get命令，其它的都是常規(guī)的數(shù)據(jù)庫(kù)操作，而且都加了索引的，所以，初步排查，數(shù)據(jù)庫(kù)這里應(yīng)該是沒(méi)有什么問(wèn)題，主要問(wèn)題可能還是集中在redis這塊，調(diào)用太頻繁了。
加日志
代碼走查下來(lái)，除了那個(gè)scan改成了keys *(這個(gè)我還不知道)，基本上沒(méi)有什么問(wèn)題，加日志吧， 一小段一小段的加上日志，OK，重啟服務(wù)，壓測(cè)來(lái)一波。
當(dāng)然了，結(jié)果沒(méi)有什么變化，分析日志。
通過(guò)日志，我們發(fā)現(xiàn)，調(diào)用redis的時(shí)候時(shí)而很快，時(shí)而很慢，看起來(lái)像是連接池不夠的樣子，也就是一批請(qǐng)求先行，一批請(qǐng)求在等待空閑的redis連接。
修改redis連接數(shù)
查看redis配置，用的是單機(jī)模式，1G內(nèi)存， 連接數(shù)默認(rèn)的8，客戶端還是比較老的jedis，果斷改成springboot默認(rèn)的lettuce，連接數(shù)先調(diào)整為50，重啟服務(wù)，壓一波。
平均響應(yīng)時(shí)間從3~4秒降到了2~3秒，并不明顯，繼續(xù)加大連接數(shù)，因?yàn)槲覀兪?000個(gè)并發(fā)，每個(gè)請(qǐng)求都有很多次redis操作，所以，肯定會(huì)有等待，這次我們把連接數(shù)直接干到了1000，重啟服務(wù)，壓一波。
事實(shí)證明，并沒(méi)有明顯地提升。
再次查看日志
此時(shí)，已經(jīng)沒(méi)有什么好的解決辦法了，我們?cè)俅位氐饺罩局?，查看redis相關(guān)操作的時(shí)間，發(fā)現(xiàn)99%的get操作都是很快返回的，基本上是在0~5毫秒之間，但是，總有那么幾個(gè)達(dá)到了800~900毫秒才返回。
我們以為redis這塊沒(méi)什么問(wèn)題了。
但是，壓測(cè)了好幾次，時(shí)間一直提不上去。
很無(wú)奈了，此時(shí)，已經(jīng)半夜3點(diǎn)多了，領(lǐng)導(dǎo)發(fā)話，把華為云的人喊起來(lái)。
華為云排查
最后，我們把華為云相關(guān)的人員喊起來(lái)一起排查問(wèn)題，當(dāng)然，他們是不情愿的，但是，誰(shuí)讓我們給錢了呢^^
華為云的負(fù)責(zé)人，把redis的專家搞起來(lái)，幫我們看了下redis的指標(biāo)，最后，發(fā)現(xiàn)是redis的帶寬滿了，然后觸發(fā)了限流機(jī)制。
他們臨時(shí)把redis的帶寬增大三倍，讓我們?cè)賶簻y(cè)一波。
握了顆草，平均響應(yīng)時(shí)間一下子降到了200~300毫秒!!!!
真的是握了顆草了，這就有點(diǎn)坑了，你限流就算了，帶寬滿了也不報(bào)警一下的么。。
這真是個(gè)蛋疼的問(wèn)題。
到這里，我們以為問(wèn)題就這樣解決了，領(lǐng)導(dǎo)們也去睡覺(jué)了~~
上生產(chǎn)
既然問(wèn)題原因找到了，那就上生產(chǎn)壓一波吧~
我們讓華為云的專家把生產(chǎn)的帶寬也增大了三倍大小。
從生產(chǎn)提交拉一個(gè)hotfix分支，關(guān)閉簽名，重啟服務(wù)，壓測(cè)走一波。
完蛋，生產(chǎn)環(huán)境更差，平均響應(yīng)時(shí)間在5~6秒。
測(cè)試環(huán)境我們是改了連接池配置的，生產(chǎn)環(huán)境還是jedis，改之，走一波。
并沒(méi)有什么實(shí)際作用，還是5~6秒。
真是個(gè)蛋疼的問(wèn)題。
查看監(jiān)控
查看華為云中redis的監(jiān)控，這次帶寬、流控都是正常的。
這次不正常的變成了CPU，redis的CPU壓測(cè)的時(shí)候直接飆到了100%，導(dǎo)到應(yīng)用響應(yīng)緩慢。
再次喚醒華為云redis專家
已經(jīng)凌晨四點(diǎn)多了，大家已經(jīng)沒(méi)什么思路了，華為云的redis專家，你給我再起來(lái)!
再次喚醒華為云的redis專家，幫我們分析了下后臺(tái)，發(fā)現(xiàn)10分鐘內(nèi)進(jìn)行了14萬(wàn)次scan~~
萬(wàn)惡的scan
詢問(wèn)研發(fā)人員哪里用到了scan(前面他們改的，我不知道)，發(fā)現(xiàn)，每次請(qǐng)求都會(huì)調(diào)用scan去拿某個(gè)前綴開(kāi)頭的key，每次掃描1000條數(shù)據(jù)，查看redis鍵總數(shù)，大概有11萬(wàn)條，也就是說(shuō)，一個(gè)請(qǐng)求就要scan100次，1000并發(fā)，大概就是10幾萬(wàn)次scan，我們知道，redis中scan和keys *是要進(jìn)行全表掃描的，非常消耗CPU，14萬(wàn)次scan操作，直接讓CPU上天了。
為什么測(cè)試環(huán)境CPU沒(méi)有上天呢?
對(duì)比了下，測(cè)試環(huán)境和生產(chǎn)環(huán)境redis的鍵總數(shù)，測(cè)試環(huán)境只有900個(gè)key，每次請(qǐng)求也就scan一次或者keys *一次，毛線問(wèn)題都沒(méi)有。
為什么生產(chǎn)環(huán)境有這么多key?
詢問(wèn)研發(fā)人員，為什么生產(chǎn)環(huán)境有這么多key，沒(méi)有設(shè)置過(guò)期時(shí)間嗎?
研發(fā)人員說(shuō)設(shè)置了的，是另一個(gè)同事寫(xiě)的代碼，打開(kāi)代碼，真是一段魔性的代碼，具體代碼我就不方便貼出來(lái)了，里面有根據(jù)條件判斷要不要設(shè)置過(guò)期時(shí)間，經(jīng)過(guò)分析，大部分情況下，都沒(méi)有設(shè)置過(guò)期時(shí)間成功。
當(dāng)前解決辦法
此時(shí)，已經(jīng)凌晨4點(diǎn)半了，雖然大家還很興奮，但是，經(jīng)過(guò)領(lǐng)導(dǎo)決策，暫時(shí)先不動(dòng)了，因?yàn)?，目前A系統(tǒng)已經(jīng)暫停調(diào)用B系統(tǒng)了，所以，此時(shí)B系統(tǒng)可以說(shuō)流量幾乎為0了，我們白天再分兩個(gè)階段來(lái)修復(fù)這個(gè)問(wèn)題。
第一步，先清理掉生產(chǎn)環(huán)境redis的數(shù)據(jù)，只保留一小部分必要的數(shù)據(jù)。
第二步，修改scan某前綴開(kāi)頭的數(shù)據(jù)，改成hash存儲(chǔ)，這樣可以減少掃描的范圍。
好了，本次生產(chǎn)事故排查就到這里了，后續(xù)，彤哥，也會(huì)繼續(xù)跟進(jìn)的。
總結(jié)
本次生產(chǎn)事件跟以往遇到的事件都略有不同，大概總結(jié)一下：
以往都是應(yīng)用服務(wù)本身的CPU、內(nèi)存、磁盤(pán)、JVM這些問(wèn)題，redis的帶寬和限流還是第一次遇見(jiàn);
上了華為云以后，很多東西還沒(méi)有弄得熟練，包括監(jiān)控指標(biāo)這些，還需要慢慢摸索;
redis一定要禁用掉keys和scan命令，且大部分key應(yīng)該設(shè)置過(guò)期時(shí)間!
好了，本次事件大概就寫(xiě)這么多，后續(xù)有新的情況彤哥也會(huì)繼續(xù)跟進(jìn)的，當(dāng)然，最好不要有新的情況^^
本文轉(zhuǎn)載自微信公眾號(hào)「彤哥讀源碼」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系彤哥讀源碼公眾號(hào)。
新聞名稱：記一次生產(chǎn)事故：30萬(wàn)單就這樣沒(méi)了！
本文鏈接：http://m.5511xx.com/article/dhodegj.html
