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