Redis里怎么精确搞定过期时间，过期时间到底咋算的那些事儿

关于Redis里怎么精确搞定过期时间，以及过期时间到底咋算的那些事儿，其实核心就是理解Redis提供的几个命令和它内部的一些运作机制，咱们不用那些复杂的术语,就用人话把这事儿说清楚。

第一部分：设置过期时间的“家伙事儿”（命令）

在Redis里，给一个键（key）设置过期时间，最常用的就是两个命令：EXPIRE 和 TTL,你可以把它们想象成给食物设定保质期的工具。

• EXPIRE key seconds：这个命令最简单直接，比如你有一个键叫 user:1000:session，你想让它在30分钟后自动消失，那就用 EXPIRE user:1000:session 1800，这里的1800就是秒数，3060=1800秒，这个命令是给一个已经存在*的键设置过期时间，根据Redis官方文档（来源：Redis命令文档），这个命令执行成功后会返回整数1,如果键不存在则返回0。

• SET key value EX seconds：这是更常用、更省事的方法，你在创建这个键值对的同时，就直接给它定好“寿命”。SET user:1000:session "abc123" EX 1800，这一条命令干了俩事儿：一是把值存进去了，二是设好了1800秒后过期，这比先SET再EXPIRE要高效，因为只需要一次网络通信，根据Redis官方文档（来源：SET命令说明），这里的EX选项就是用来设置以秒为单位的过期时间。

• PEXPIRE 和 SET ... PX ...：这两个是上面两个命令的“高精度版”。EXPIRE和SET...EX...的单位是秒，有时候我们可能需要更精确的控制，比如毫秒级别，这时候就用PEXPIRE key milliseconds 或者 SET key value PX milliseconds，比如设置一个仅存在500毫秒的临时键：SET temp:lock "1" PX 500。

• TTL key 和 PTTL key：这是用来“查保质期还剩多久”的命令。TTL返回的是剩余的秒数，PTTL返回的是剩余的毫秒数，根据Redis官方文档（来源：TTL命令文档），这个命令的返回值非常有意思,它告诉你三种情况：

  • 返回一个大于0的整数：比如返回150,意思就是这个键还有150秒就过期了。
  • 返回 -1：这意味着这个键根本就没有设置过期时间，它会永久存在,除非你手动删除它。
  • 返回 -2：这意味着你查询的这个键已经过期被删除了，或者压根就不存在。

第二部分：过期时间到底从哪一秒开始算？（咋算的）

这是个关键问题，过期时间的计算起点不是你执行EXPIRE命令的那个时刻，而是Redis服务器成功执行完设置过期时间的那个命令的时刻。

举个例子，你执行了 EXPIRE mykey 60，这个命令从你的客户端发出去，需要一点点网络传输时间，到达Redis服务器，服务器再处理这个命令，这个过程的耗时可能只有1毫秒或者几毫秒，过期时间的60秒，是从服务器处理完这个命令,成功将过期时间记录下来的那一瞬间开始倒计时的。

这个计算是非常精确的，是基于Redis服务器自身时钟的，这也引出了一个重要前提：Redis服务器的系统时间必须是准确的，如果服务器时间快了或者慢了,那过期时间自然也就不准了。

第三部分：Redis是怎么在背后“悄悄地”删除过期键的？（精确搞定的核心）

你以为Redis是拿着个秒表，死死地盯着每一个键，时间一到就立刻删除吗？不是的，那样太消耗CPU资源了，Redis采用了一种“惰性删除”和“定期删除”相结合的策略，根据《Redis设计与实现》一书中的描述（来源：《Redis设计与实现》第四章）,这套机制是这样的：

1. 惰性删除：这是被动策略，当客户端尝试去访问一个键的时候，Redis会先检查一下这个键是否设置了过期时间，以及是否已经过期，如果过期了，Redis会立刻删除这个键，然后返回一个“此键不存在”的提示给客户端，这样做的好处是，CPU只用在需要的时候才花费力气去删除，不浪费资源，但坏处是，如果某个过期的键永远没人访问，那它就永远占着内存，成了“垃圾”。

2. 定期删除：这是主动策略，用来弥补惰性删除的不足，Redis会每隔一段时间（默认是每秒10次，即100毫秒一次）就随机地抽取一部分设置了过期时间的键进行检查（注意是随机抽一部分，不是检查全部，否则CPU压力会很大），如果发现有过期的键，就把它删除掉，这个“定期清理”的过程，保证了即使没有客户端访问，那些过期键最终也会被清理掉,避免了内存的无限增长。

第四部分：需要注意的几个“坑”

理解了上面的机制,你就能明白一些特殊情况：

• 复制（Replication）和持久化（Persistence）下的表现：在Redis主从架构中，过期键的删除是由主节点（Master）控制的，主节点在删除一个过期键时，会显式地向所有从节点（Slave）发送一个DEL命令，通知从节点也删除这个键，这样可以保证主从数据的一致性，而在持久化（RDB或AOF）时,过期的键是不会被保存到快照或日志文件中的。

• 时间漂移问题：正如前面提到的，Redis依赖服务器系统时间，如果你的服务器时间因为某种原因发生了跳变（比如被NTP服务同步调整了），那么所有过期时间的计算都会受到影响，可能导致键提前或延后过期,保持服务器时间稳定非常重要。

在Redis里精确搞定过期时间,你需要：

1. 根据精度要求选对命令：EXPIRE/SET EX（秒级）或PEXPIRE/SET PX（毫秒级）。
2. 理解过期时间是从服务器端命令执行成功时开始计算的。
3. 明白Redis通过“惰性+定期”的混合删除策略来清理过期键，这既是高效的设计，也意味着过期键的删除有微小的、可接受的延迟。
4. 在分布式环境和持久化场景下,了解过期键处理的特殊规则。
5. 确保服务器时钟准确,这是所有时间相关操作精确的基础。