Redis时间设置到底准不准？怎么看和调时间的小技巧分享

关于Redis的时间设置到底准不准这个问题，答案其实有点微妙：在大多数常规应用场景下，Redis的时间是“够用”的，但如果你需要极高精度的时间同步，它可能并不完全准确。 我们不能把它当成像原子钟那样分秒不差的计时器。

为什么这么说呢？这得从Redis的工作原理说起，根据Redis官方文档（redis.io）中的说明，Redis服务器内部维护了一个服务器状态（server state），其中就包含了当前时间的缓存。关键点在于，Redis并不会实时地去系统获取时间戳。 因为获取系统时间（比如调用gettimeofday()这样的系统调用）本身是一个相对昂贵的操作，如果每次处理命令、设置过期时间（TTL）都要去问一次系统“现在几点了？”,那会对性能造成不小的影响。

Redis采取了一种折中的策略：它内部有一个定时任务，会以一定的频率（默认每秒10次，即100毫秒一次）去更新这个缓存的时间戳。 这意味着，在两次更新之间，Redis内部使用的“当前时间”其实是静止的，对于设置一个未来5秒后过期的键来说，这100毫秒的误差几乎可以忽略不计，但对于需要毫秒级甚至微秒级精度的场景，比如高频交易或者极其精确的延迟计算,这个误差就可能成为问题。

我们怎么查看Redis的时间呢？

最简单直接的方法就是使用Redis自带的命令,最常用的有两个：

1. TIME命令：这个命令会直接返回一个包含两个元素的数组，第一个元素是当前的UNIX时间戳（秒级），第二个元素是微秒数，这个命令的特别之处在于，它返回的是Redis执行TIME命令那一瞬间，直接从操作系统获取的实时时间，而不是它内部缓存的那个时间。 当你需要知道精确的当前时间时,应该使用这个命令。

   

   • 返回 1) "1717589123" 2) "123456"，这表示当前时间是2024年6月5日左右（从1970年1月1日算起的1717589123秒）,再加上123456微秒。

2. INFO server命令：在这个命令返回的大量信息中，你可以找到两行：uptime_in_seconds（服务器已运行秒数）和uptime_in_days（服务器已运行天数），你可以用当前系统的实时时间减去uptime_in_seconds，来反推Redis服务器的启动时间，但这通常用于监控和排查问题，不如TIME命令直接。

聊聊调整时间的小技巧和注意事项。

最重要的一点是：永远不要试图在Redis服务器内部去修改系统时间！ Redis本身没有提供任何命令来修改服务器的时间,时间的源头是它运行所在的操作系统。

调整Redis的时间，本质上就是调整它所在服务器的系统时间,这里有几个关键技巧：

1. 使用NTP同步是黄金法则：确保运行Redis的服务器都配置了网络时间协议（NTP）服务，并指向可靠的时间服务器（如time.windows.com或pool.ntp.org），这是保证分布式系统中各个节点时间基本一致的最有效方法，如果主从复制的Redis集群中，主节点和从节点的时间相差太大,可能会带来数据不一致的风险。

2. 避免时间突然跳变：这是最危险的情况，如果你用手动命令（比如Linux下的date -s）大幅度地向前或向后修改系统时间,会对Redis造成严重影响。

   • 键过期混乱：Redis依赖单调递增的时间来判断键是否过期，如果时间突然被调回到过去，那么本应已经过期的键可能会“死而复生”，在过期时间再次到达之前一直存在，如果时间被猛地调向未来，那么大量尚未过期的键可能会被瞬间判定为过期并被清理掉,导致数据丢失。
   • 持久化问题：Redis的持久化机制（如AOF）可能会因为时间戳的混乱而产生异常。
   • 正确做法：如果确实需要调整时间，应该使用ntpdate或chrony等工具进行“步进式”调整，或者让NTP服务自己慢慢地校准,避免出现大的时间跳跃。

3. 关注slowlog和监控中的时间信息：Redis的慢查询日志（slowlog）会记录每个慢查询的执行时间戳，这个时间戳是基于Redis内部缓存时间的，当你分析慢查询发生的原因时，这个时间点可以帮你结合系统监控（如CPU、内存峰值）进行定位，同样，各种监控系统采集Redis的INFO信息时，也会包含时间相关的数据,是判断系统运行状态的重要参考。

4. 对于高精度需求的变通方案：如果你的应用场景对时间精度要求极高，一个常见的做法是将Redis作为存储，而将高精度计时的工作交给应用程序，应用程序在将数据写入Redis时，自己生成一个高精度的过期时间戳（比如用Java的System.currentTimeMillis()），然后在读取数据时，由应用层来判断是否已经超时,而不是完全依赖Redis的TTL机制。

看待Redis的时间，我们要把它看作一个为了性能而做了优化的、大致准确的时钟，通过使用TIME命令查看实时时间，并通过维护好服务器的NTP服务来保证时间的稳定和同步，我们就能在绝大多数情况下安心使用它，而对于时间极其敏感的场景,则需要结合应用层逻辑来弥补其固有的设计局限。