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

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