• 记录一次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,或者异步写入导致的。经同事提醒才询问运维人员是否改了服务器时间,

    知识全面才不会意外背锅(一度被别人怀疑我的代码出了问题,悲戚)。

  • 相关阅读:
    2020年7月15日Java学习日记
    2020年7月14日Java学习日记
    2020年7月13日Java学习日记
    2020年7月12日Java学习日记
    2020年7月11日Java学习日记
    2020年7月10日Java学习日记
    2020年7月9日Java学习日记
    2020年7月8日Java学习日记
    链式栈(Chain stack)
    Codeforces-1375-D-Replace by MEX
  • 原文地址:https://www.cnblogs.com/shaozhen/p/11043781.html
Copyright © 2020-2023  润新知