Redis里头过期时间那些字符串咋精准控制，感觉挺复杂又想搞明白点

你感觉Redis的过期时间控制起来复杂,这个感觉是对的，因为它确实提供了好几种不同的“开关”，用对了很方便，用混了就容易迷糊，咱们不用那些“设置键的生存时间”之类的专业说法，就把它想象成给你仓库里的东西贴不同种类的“保质期”标签。

Redis主要给了我们两种贴标签的方式,这两种方式决定了“保质期”从什么时候开始计时，这是最核心的区别。

第一种方式,叫“倒计时”标签（EXPIRE/PEXPIRE），比如你有一箱水果，你明确知道它放3天就会坏，那么在你把它放进仓库的那一刻，你就可以贴上一个标签，写上“3天后过期”，这个计时是从你贴标签的那一刻就开始的，在Redis里，对应的命令就是EXPIRE key seconds，比如SET mykey "hello"之后，马上执行EXPIRE mykey 60，那么这个mykey就在60秒后，不管有没有人动它，都会被自动清理掉，还有一个PEXPIRE，道理一模一样，只是时间单位是毫秒，用于需要更精确控制的场景，这种方式适合你心里很清楚这个东西具体的存活时长，比如验证码60秒失效、临时会话30分钟过期。

第二种方式,叫“闹钟”标签（EXPIREAT/PEXPIREAT），这个就好比你这箱水果不是3天后坏，而是必须在下周五晚上12点前处理掉，不管你是哪天放进仓库的，这时候你贴的标签就不是“3天”，而是一个具体的时间点，2024-05-24 24:00:00”，Redis里的命令是EXPIREAT key timestamp，这个timestamp通常是一个Unix时间戳（从1970年1月1日到现在经过的秒数），比如你查到现在的时间戳是1716540000，你想让这个键在明天这个时候过期，就设置EXPIREAT mykey 1716626400。PEXPIREAT也一样，对应的是毫秒级的时间戳，这种方式特别适合做类似“活动截止到某月某日”、“会员资格到期日”这种需求，过期时间是一个绝对的时刻，跟键是什么时候创建的没关系。

这里有一个非常重要的点,也是容易搞混的地方，就是标签是可以被修改或撕掉的，当你对一个已经有过期时间的键重新执行SET命令时，它身上原来的任何“保质期”标签都会被撕掉，变成一个永久有效的键，除非你再次为它设置新的过期时间，如果你只是修改这个键的值的一部分，比如用APPEND追加字符串或者用HSET修改哈希里的某个字段，那么原来的过期时间会保持不变。

除了设置,我们还得会查看和取消，查看剩余生存时间用TTL key命令，它返回的是这个键还能活多少秒，如果返回-2，说明这个键已经不存在了（可能已经过期被删了）；如果返回-1，说明这个键是永久的，从来没贴过“保质期”标签，取消过期时间，也就是把标签撕掉，让键永久有效，用的是PERSIST key命令。

Redis是怎么在后台悄无声息地处理这么多过期键的呢？它主要用了两种策略，这就像仓库管理员定时巡查和顺手检查的结合。

一种叫定期删除，Redis会每隔一段时间（默认是100毫秒）就随机抽查一批设置了过期时间的键，如果发现有过期的，就把它们扔掉，因为是指定时间做一次，并且是随机抽查，所以可能会有一小部分过期的键没有及时被清理掉，但它节省了CPU资源，避免一直检查把系统拖慢。

另一种叫惰性删除，这个就是“用到的时候才检查”，当有客户端尝试去读取一个键时，Redis会先看一眼这个键的“保质期”标签，如果发现已经过期了，它会立刻把这个键删除，然后告诉客户端“这个键不存在”，这种方式保证了客户端永远不会读到过期数据，但缺点是如果很多过期键永远不再被访问，它们就会一直占着内存，直到被定期删除扫到为止。

实际Redis是结合这两种方式工作的,既定期打扫，也等你要用的时候再确认一下，在精确度和性能之间取了个平衡。

还有一个高级玩法,就是在存放数据的同时直接设置过期时间，这相当于把“放东西”和“贴标签”两个动作合成一步，非常方便，主要命令是SET key value EX seconds 或者 SET key value PX milliseconds，比如你存一个验证码，直接SET code 123456 EX 60，一行命令就搞定了键值对和60秒的过期时间，又准确又不会忘记设置。

想精准控制,关键就是想清楚你的业务场景：是需要一个固定的存活时长（用EXPIRE），还是一个绝对的过期时刻（用EXPIREAT），然后理解Redis删除过期键的机制，知道它可能有一点点延迟，但在绝大多数情况下是及时和准确的，养成好习惯，在设置键的时候，如果能确定过期时间，就尽量用SET ... EX这种一气呵成的命令，省事又不容易出错。