redis时钟漂移造成的 key值失效

问题现象

问题：最近客户新切了生产环境，结果有些接口不能用了，一直报“xxx失效，校验失败”，排查了一下，代码也没改动，其他环境同样也是好的。

原因

苦思不得其解，问了大佬，才知道，可能是集群内服务器时间不一样，造成redis时钟漂移，导致key值校验时已经过期了。一排查，果真如此。

那么这个redis时钟漂移到底是什么呢？为什么集群内服务器时间不一样，会导致一个设定好过期的key值提前失效呢？

详解redis时钟漂移

关键点：resis设置的过期时间，是当前服务器时间加上设定的expires时间。
场景：服务器A 在2023/6/28 00:00:00设置了 30分钟过期的key1，key1在00：30：00 失效过期，假如服务器B比服务器A快1一个小时，那么B将一直拿不到A设定的key1

解决方案

无非是让集群时间保持一致，以下将围绕这个点进行讨论

方式一：与互联网时间同步
阿里云时钟同步服务器
ntpdate ntp4.aliyun
创建 crontab 任务调度
crontab -e
*/1 * * * * /usr/sbin/ntpdate ntp4.aliyun;
输入date，测试

式二：和内网某台机器同步
参考这里

redis时钟漂移造成的 key值失效

问题现象

问题：最近客户新切了生产环境，结果有些接口不能用了，一直报“xxx失效，校验失败”，排查了一下，代码也没改动，其他环境同样也是好的。

原因

苦思不得其解，问了大佬，才知道，可能是集群内服务器时间不一样，造成redis时钟漂移，导致key值校验时已经过期了。一排查，果真如此。

那么这个redis时钟漂移到底是什么呢？为什么集群内服务器时间不一样，会导致一个设定好过期的key值提前失效呢？

详解redis时钟漂移

关键点：resis设置的过期时间，是当前服务器时间加上设定的expires时间。
场景：服务器A 在2023/6/28 00:00:00设置了 30分钟过期的key1，key1在00：30：00 失效过期，假如服务器B比服务器A快1一个小时，那么B将一直拿不到A设定的key1

解决方案

无非是让集群时间保持一致，以下将围绕这个点进行讨论

方式一：与互联网时间同步
阿里云时钟同步服务器
ntpdate ntp4.aliyun
创建 crontab 任务调度
crontab -e
*/1 * * * * /usr/sbin/ntpdate ntp4.aliyun;
输入date，测试

式二：和内网某台机器同步
参考这里