Redis里怎么搞多条数据不同时间自动过期，第二天失效咋整才方便

这个问题问得很实际，就是在Redis里，我们有一大堆数据，比如用户当天的签到记录、临时优惠券、或者一些缓存的计算结果，这些数据不是同时产生的，但我们希望它们都能在各自的“出生时间”算起，过一段时间就自动被Redis删除，特别的是，到了第二天凌晨，不管它们是什么时候出生的，要全部清空,重新开始。

要实现这个“多条数据不同时间自动过期”加上“第二天统一失效”的效果，有几种常见的、方便的做法,下面我们分开来说。

第一种方法：给每条数据设置独立的过期时间（TTL）

这是最直接的想法，既然每条数据存活的时间长度是一样的（比如都是24小时），那我们就在把数据存入Redis的时候，同时设置一个过期时间（TTL）。

• 怎么做：假设我们用命令来操作，当用户A在今天下午2点签到后，我们存入一条数据，键（Key）可以是 user_sign_in:A:20240520，值（Value）是签到信息，我们给这个键设置一个过期时间，EXPIRE key 86400（86400秒就是24小时），这样,这条数据就会在明天下午2点自动过期被删除。
• 优点：实现起来非常简单直观，Redis原生支持,每条数据的管理是独立的。
• 缺点：对于“第二天失效”这个需求，它其实是一种“滑动”的失效，如果数据是在晚上11点产生的，它就会在第二天晚上11点失效，而不是在第二天凌晨零点整失效，这不符合“第二天”通常指的是日期变更时就失效的语义，如果数据量巨大，频繁设置TTL对Redis的性能有轻微影响,但通常可以接受。

第二种方法：使用基于时间的键名，配合统一的过期策略

这个方法非常巧妙地规避了设置独立TTL的麻烦，特别适合解决“第二天统一失效”的问题。

• 怎么做：我们不再给每条数据设置很长的过期时间，而是在键名里带上日期，用户A在5月20日签到，我们存的键名就是 user_sign_in:A:20240520，用户B在同一天签到，键名是 user_sign_in:B:20240520。 如何实现自动过期呢？我们给所有这些带日期的键设置一个相对较短的、固定的过期时间，EXPIRE key 36小时，为什么是36小时？这是为了保证无论数据是在5月20日的凌晨00:01还是晚上23:59存入的，都能安然度过5月20日这一天，并且在5月21日过去之后的某个时间点（比如5月22日中午左右）被自动清理掉。
• 优点：
  1. 完美解决统一失效：到了5月21日，我们业务上要查询“的签到数据时，我们会自动去生成并查询新的键 user_sign_in:A:20240521，对于业务来说，5月20日的旧数据虽然还在Redis里，但已经被“逻辑上”废弃了，因为程序不再读取它们,Redis会在之后的一段时间里自动清理掉它们。
  2. 管理方便：不需要为每条数据计算复杂的TTL，可以批量设置过期时间,甚至可以通过配置一个Redis的默认过期时间来实现。
  3. 清晰明了：通过键名就能直接看出数据属于哪一天,排查问题时非常方便。
• 缺点：需要确保业务代码在生成键名时，能正确拼接上日期，过期时间需要设置得足够长（比如大于36小时），以确保不会出现“旧一天的数据在新一天还没完全结束时就被误删”的情况。

第三种方法：使用Redis的排序集合（Sorted Set）

这个方法比较进阶，但非常强大和精确,尤其适合需要严格在某个时间点进行批量操作的情况。

• 怎么做：我们可以利用Sorted Set的一个特性：每个成员（Member）都有一个分数（Score），我们可以把“数据的键名”作为成员，而把“该数据应该过期的那个时间点”的时间戳（一个很大的数字）作为分数。 我们想要所有数据都在2024年5月21日凌晨00:00过期，无论用户A、B、C在5月20日什么时候签到，我们都把他们的签到记录键（sign_info_A）作为成员，加入到同一个Sorted Set中（比如键叫 daily_expire_queue），并把分数统一设置为 1716249600（这是2024年5月21日00:00:00的时间戳）。 我们需要一个定时任务（比如用Cron Job，或者Redis内部的Lua脚本定时执行），这个任务定期地检查这个Sorted Set，它使用 ZRANGEBYSCORE daily_expire_queue 0 当前时间戳 命令，来取出所有分数小于等于当前时间戳的成员（也就是所有已经到达过期时间的键），遍历这些取出的键名，逐个删除（DEL）它们对应的实际数据，最后再从Sorted Set中移除这些成员。
• 优点：可以实现非常精确的、在指定时间点（比如每天零点整）的批量过期删除,控制力极强。
• 缺点：实现起来最复杂，需要额外的定时任务机制，并且这个删除操作不是Redis自动完成的，如果定时任务挂了，数据就永远无法自动清理，它也会在删除瞬间对Redis产生一定的压力（如果数据量极大的话），这是一种“主动”清理策略，而非前两种的“被动”过期。

总结一下该怎么选

• 如果对“第二天零点整”失效的要求不是特别严格，允许数据在其创建24小时后失效即可，那么第一种方法（设置独立TTL） 最简单。
• 如果强烈要求数据在日期变更时就在逻辑上失效，并且希望管理简单，那么第二种方法（键名带日期） 是最推荐、最方便的做法,这也是很多互联网公司的常见实践。
• 如果需要绝对精确地在午夜零点执行物理删除，并且不介意架构复杂一点，可以考虑第三种方法（Sorted Set加定时任务）。

针对你的问题“第二天失效咋整才方便”，答案通常是第二种方法：在键名中嵌入日期，并设置一个足够长的统一过期时间（比如36小时），这样，业务上通过键名自然区分了新旧数据，实现了“逻辑上的次日失效”，而物理上的删除则交给Redis自动完成,省心又省力。