标签：策略 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，或者异步写入导致的。经同事提醒才询问运维人员是否改了服务器时间，
知识全面才不会意外背锅(一度被别人怀疑我的代码出了问题，悲戚)。
标签：策略 redis 服务器时间 应用 写入 时间 导致 创建 中间
原文地址：https://www.cnblogs.com/shaozhen/p/11043781.html
