Redis怎么统一过期时间，保证数据安全不出错的那些事儿

主要基于Redis官方文档的持久化机制、过期键删除策略以及常见的运维实践经验进行阐述）

Redis作为一个非常快的内存数据库，我们用它来存很多东西，比如用户的登录信息、页面的缓存数据、还有临时的验证码等等，这些数据很多都不是需要永久保存的，所以我们会给它们设置一个过期时间，到时候Redis会自动把它们删掉，这样既能节省内存，也省去了我们手动清理的麻烦，这个“自动过期”听起来简单，背后却有不少门道，如果没弄好，可能会导致数据该删的时候没删，或者不该删的时候却被删了，造成一些意想不到的错误，今天我们就来聊聊，怎么才能把Redis的过期时间管理好,让数据既安全又听话。

我们得知道Redis是怎么判断一个数据有没有过期的，Redis给每个可以过期的数据都打上了一个“死亡时间戳”，当你设置一个键（key）的过期时间为60秒后，Redis并不是启动一个倒计时器在那里盯着，而是会在内部记录下“当前时间戳 + 60秒”这个未来的时间点，之后，Redis会不断地检查，如果当前时间已经超过了那个记录下来的时间点,就认为这个键过期了。

知道了怎么判断过期，下一个问题就是：Redis什么时候、用什么方式来删除这些过期的键呢？这里就有两种主要的策略了，它们像是两个清洁工,干活的方式很不一样。

第一种清洁工，我们叫他“懒惰型清洁工”，他的工作原则是“你不问我，我就不动”，意思是，只有当客户端（也就是我们的应用程序）尝试去访问一个键的时候，这个清洁工才会被触发，他会先看一眼这个键的“死亡时间戳”，如果发现已经过期了，就立刻把它删掉，然后返回一个“这个键不存在”的信息给客户端，这种方式的优点是非常省力气，因为只会在真正需要的时候才干活，对Redis的性能影响最小，但缺点也很明显，如果一个过期键一直没人去访问，它就会一直占着内存不释放，成了“内存垃圾”。

为了解决“懒惰型清洁工”的缺点，Redis派出了第二个清洁工，我们叫他“定期型清洁工”，这个清洁工会主动出击，每隔一段时间就巡逻一下，抽查一部分设置了过期时间的键，把其中已经过期的清理掉，这个巡逻的过程是分批次、渐进式进行的，不会一次性检查所有键，以免让Redis卡住无法响应其他请求，通过这种方式，Redis能够在一定程度上及时清理掉那些长期无人访问的“内存垃圾”。

在实际使用中，我们怎么结合这两个清洁工的特性来保证数据安全呢？这里有几个需要注意的地方。

第一，不要过分依赖“懒惰删除”，如果你的应用里有大量一次写入后就再也不读取的数据，那么即使它们过期了，也会因为没人访问而长期滞留，最终可能导致内存被耗尽（OOM），对于这种“写后即弃”型的数据，你需要评估内存消耗,或者考虑主动触发清理。

第二，理解数据消失的“不确定性”，由于删除主要靠“定期”和“懒惰”两种方式，一个键在过期后，并不会在精确的那一毫秒被删除，它可能会在几毫秒后，也可能在几秒后才被清理掉，你的应用程序逻辑不能建立在“键一定会在过期时间点准时消失”的假设上,这是Redis为了平衡性能和准确性所做的设计妥协。

第三，持久化时的陷阱，Redis有两种把内存数据保存到硬盘上的方式，叫做RDB和AOF,这相当于给数据做了备份。

• 当生成RDB快照时，Redis只会保存那些没有过期的键，如果你的备份文件里没有某个键，要么是它被删了,要么是它在备份那一刻过期了。
• 当使用AOF日志追加方式时，情况有点不一样，当一个键过期被删除后，Redis会在AOF文件里追加一条删除该键的命令，这样，当Redis重启后，通过回放AOF文件，它就会重新执行这个删除操作,保证了数据状态的一致。

但这里有个关键点：如果你在数据恢复时，使用的是RDB文件，那么要注意，RDB文件本身不包含已经过期的键，从RDB恢复后，所有键的过期时间是从恢复那一刻开始重新计算的吗？不是的，Redis很聪明，它在RDB文件里同时保存了键的“死亡时间戳”，恢复时，它会检查这个时间戳，如果发现这个时间戳已经早于当前时间（也就是在备份之后就已经过期了），那么这个键根本就不会被加载到内存里，只有那些时间戳还未到的键才会被恢复，并且它们的剩余存活时间会按照备份时的时间戳来计算，这个机制非常重要，它避免了恢复一个已经过期的数据,从而可能引发的逻辑错误。

第四，统一”过期时间的技巧，我们可能希望一批相关的数据在同一时刻过期，比如一个大型活动的所有缓存，直接给每个键设置相同的TTL（生存时间）并不能保证它们同时过期，因为写入操作有先后顺序，一个更可靠的方法是，使用一个统一的、未来的绝对时间点（Unix时间戳）作为所有键的过期时间，都设置为明天零点整过期，这样，无论你在今天什么时候写入，这些键都会在同一个精确的时刻失效，实现了真正的“统一过期”。

要让Redis的过期时间机制安全可靠地工作，我们需要理解其背后的“懒惰删除”和“定期删除”原理，并在设计应用时注意：避免产生大量永不访问的过期键、接受过期删除的时间不确定性、了解持久化机制对过期键的处理逻辑，以及在需要严格统一过期时使用绝对时间戳，把这些“事儿”弄明白了，我们就能更好地驾驭Redis,让它既快又稳地为我们的业务服务。