记录一次redis事故
公司在搞一次活動(dòng)時(shí),服務(wù)器一個(gè)應(yīng)用服務(wù)出現(xiàn)異常,結(jié)果導(dǎo)致前端不斷請(qǐng)求最終導(dǎo)致請(qǐng)求量過(guò)大,資源耗盡。
追蹤原因:
1、調(diào)出應(yīng)用日志,發(fā)現(xiàn)這個(gè)請(qǐng)求為獲取微信信息的接口,微信的access_token過(guò)期了導(dǎo)致微信拒絕服務(wù)
2、猜測(cè)是微信token創(chuàng)建接口被多個(gè)服務(wù)重復(fù)刷新導(dǎo)致access_token過(guò)期,由于存儲(chǔ)在redis中,查看信息發(fā)現(xiàn)居然還有9個(gè)多小時(shí)有效期,實(shí)際上所有程序中寫(xiě)的都是2個(gè)小時(shí),迷惑
3、調(diào)出access_token創(chuàng)建日志,發(fā)現(xiàn)是6月18號(hào)創(chuàng)建的(當(dāng)前時(shí)間),實(shí)際上是17號(hào)創(chuàng)建的,詢(xún)問(wèn)運(yùn)維人員說(shuō)是為測(cè)試另一個(gè)項(xiàng)目將服務(wù)器時(shí)間往后推了24小時(shí),gg。。。
4、經(jīng)查詢(xún)資料得知,redis過(guò)期策略是預(yù)先算出過(guò)期的時(shí)間戳,然后中間不斷將當(dāng)前時(shí)間與該時(shí)間戳比較。17號(hào)5:40創(chuàng)建了access_token,過(guò)期時(shí)間點(diǎn)應(yīng)該是7:40,但服務(wù)器時(shí)間改動(dòng)導(dǎo)致時(shí)間戳是18號(hào)7:40,后來(lái)服務(wù)器又恢復(fù)了正常時(shí)間,最終導(dǎo)致過(guò)期時(shí)間被延長(zhǎng)了24小時(shí)
?
原因總結(jié):
服務(wù)器時(shí)間不能亂改,懂得redis原理很重要!!!!!!
?
意外教訓(xùn):開(kāi)始不知道服務(wù)器時(shí)間改了,在查看logback日志時(shí)發(fā)現(xiàn)時(shí)間記錄上面的居然比下面的還新,同一個(gè)日志文件上面是18號(hào)的日志,下面居然變成了17號(hào),一度以為是logback出了bug,或者異步寫(xiě)入導(dǎo)致的。經(jīng)同事提醒才詢(xún)問(wèn)運(yùn)維人員是否改了服務(wù)器時(shí)間,
知識(shí)全面才不會(huì)意外背鍋(一度被別人懷疑我的代碼出了問(wèn)題,悲戚)。
轉(zhuǎn)載于:https://www.cnblogs.com/shaozhen/p/11043781.html
總結(jié)
以上是生活随笔為你收集整理的记录一次redis事故的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 安全测试基础 -- 概述【转载】
- 下一篇: 自编码器及其相关模型