1. 为什么面试官总爱问过期时间这个问题背后的真实考察点先直接说结论几乎所有Redis相关的技术面试都绕不开键的过期时间这道题。很多人觉得这就是背两条命令的事——EXPIRE管超时PERSIST管取消——但面试官真正想听的远不止这两个单词。我在帮团队做技术面试时发现候选人分两类。一类能流畅说出EXPIRE key seconds设置过期时间TTL查看剩余时间PERSIST移除过期时间但问到过期键是怎么被删除的大量键同时过期会怎样为什么有时候内存明明没满Redis却变慢了就卡壳。另一类能把这条命令背后的一整套机制串起来讲清楚还能顺带说出自己在生产环境踩过的坑。说实话只要候选人能讲到第二类的六七成深度在我这里基本就算过关了。这道题之所以高频是因为它表面考命令实际考三件事第一对Redis内存淘汰策略的理解。过期键本身占内存如果只设置不清理Redis迟早被垃圾数据撑爆。面试官想确认你清楚过期和被删除之间的时间差以及Redis到底用什么机制来兜底。第二对Key生命周期的掌控能力。实际业务里Session、验证码、限流计数器、临时缓存全都依赖过期时间来实现自动失效。一个合格的开发者得能在合适的场景选择正确的过期策略而不是所有键都无脑设置一个14400秒了事。第三对底层数据结构的熟悉程度。过期信息存在哪为什么EXPIRE的精度能到毫秒TTL返回-1和-2分别是什么意思这些都指向《Redis设计与实现》里讲到的过期字典expires dict。所以这篇文章不想只停留在背命令层面。我会从命令用法讲起逐个拆解背后的实现原理、删除策略、常见误区和生产环境的最佳实践。无论你是马上要面Redis岗位的候选人还是已经在用Redis但想补足这块知识盲区的开发按这个思路捋一遍再遇到相关问题心里就有底了。2. 命令全景设置、查看、取消与批量操作的完整用法2.1 最基本的三板斧EXPIRE、TTL、PERSIST先过一遍最核心的命令保证不熟的读者有个明确抓手。EXPIRE设置过期时间单位秒EXPIRE key seconds举个实际例子。用户登录后我给他生成一个token并写入Redis希望30分钟后自动失效SET session:token:9527 a1b2c3d4 EXPIRE session:token:9527 1800执行成功后返回(integer) 1表示设置成功。如果key不存在返回(integer) 0这一点很关键——很多人以为对不存在的key执行EXPIRE会报错其实它只是安静地告诉你没设置上。TTL查看剩余存活时间单位秒TTL key返回三种典型的取值大于0的正整数剩余多少秒过期。-1键存在但没有设置过期时间即永久有效。-2键不存在可能从未存在也可能已过期被清理。有个细节容易忽略TTL返回的是秒但精度其实可以到毫秒级。如果要精细查看用PTTL key返回剩余毫秒数。同理设置超时更精确的命令是PEXPIRE key milliseconds。PERSIST移除过期时间让键永久有效PERSIST key这个命令会把键从过期字典里移除之后它就一直存在除非你手动DEL。执行成功返回(integer) 1如果键本身就没有过期时间返回(integer) 0这种情况并不算错误。2.2 容易混的SETEX和SETNX一条命令解决写入设过期实际业务里最常见的场景是我想设置一个缓存如果不存在就写入并设置过期时间如果存在就忽略。新手容易写成两步SET key value EXPIRE key 60这里埋着一个隐患假如第二步执行前程序崩溃key就成了没有过期时间的永久键缓存就泄漏进Redis了。所以Redis官方推荐用原子操作一步完成。最常用的是SET命令的扩展参数SET key value EX 60 NX其中EX 60表示60秒后过期NX表示只有key不存在时才写入。组合起来就是业界最常说的分布式锁最简实现。还有一个专门的命令SETEXSETEX key 60 value它就是写值设过期的原子版本。另一个经常被问到的SETNX key value只在不存在时设置但这个命令没有过期参数所以如果你用SETNX实现分布式锁还需要单独调EXPIRE两步操作非原子存在锁永远不释放的风险。这也是为什么Redis官方后来推荐直接用SET key value EX seconds NX而不是SETNX EXPIRE组合。2.3 批量场景怎么处理MULTI事务与Lua脚本如果需要对多个键设置不同的过期时间可以逐条执行但在生产环境里多个命令的原子性是个问题。举个例子初始化一批活动数据10个键打包写入并设过期如果写到第5个时超时或报错前面的键就变成了永久键。两种推荐做法方案一MULTI事务MULTI EXPIRE key1 3600 EXPIRE key2 3600 EXPIRE key3 3600 EXECMULTI能让这些命令按顺序一次性执行中间不会插入其他客户端的命令原子性有保障。方案二Lua脚本eval for i1, #KEYS do redis.call(expire, KEYS[i], ARGV[1]) end 3 key1 key2 key3 3600Lua脚本的好处是可以写复杂逻辑但注意别把大循环塞进脚本会阻塞Redis单线程。一般的批量设过期用事务就够了没必要上Lua。2.4 表格式速查一张表看懂全部相关命令整理一张速查表面试前扫一眼很方便。命令作用返回值含义典型使用场景EXPIRE key seconds设置过期时间秒1成功 / 0键不存在通用过期设置PEXPIRE key ms设置过期时间毫秒1成功 / 0键不存在对时间精度有要求TTL key查看剩余秒数正数剩余秒-1永久-2不存在检查缓存是否快过期PTTL key查看剩余毫秒数同上单位换为毫秒精细监控PERSIST key移除过期时间1成功 / 0原本无过期让键永久有效EXPIREAT key timestamp设置到某个时间点过期秒级时间戳1成功 / 0键不存在定时失效场景PEXPIREAT key timestamp_ms设置到某个时间点过期毫秒级时间戳1成功 / 0键不存在精度要求高的定时失效SET key value EX s写入并设过期原子OK缓存写入SETEX key s value同上命令专用版OK缓存写入SET key value NX EX s不存在才写入并设过期OK / nil分布式锁、防击穿缓存这表里的EXPIREAT值得多说一句它接收的是绝对时间戳。比如希望键在明天零点整失效可以先把具体时间转成Unix时间戳再传进去。好处是无论什么时候执行命令失效时间点都固定。坏处是如果服务器时间被调整行为会跟着变生产环境更推荐用相对时间EXPIRE。3. 底层机制拆解过期键的存储结构、惰性删除与定期删除3.1 过期字典Redis怎么知道一个键什么时候死Redis的每个数据库结构里除了保存所有键值对的dict还维护了一个过期字典expires dict。后者的key是指向某个键的指针value是过期的时间戳毫秒级。可以这么理解主字典相当于一个住户登记表记录每户住着谁key-value过期字典相当于一个房租到期日备忘本只记录哪一户什么时候该搬走。两个字典通过指针关联平时互不干扰。当执行EXPIRE key 100时Redis做了两件事在主字典里找到key对应的对象。把当前时间 100秒写入过期字典以key为索引。当执行PERSIST key时Redis所做的就是从过期字典里删掉这条记录。如果这个key本来就不在过期字典里返回0。为什么需要单独维护一个dict而不是在value结构体上直接加一个过期字段因为过期是键的附加属性不是值本身的属性。用独立字典的好处是内存淘汰、过期判断、持久化等多个模块都可以直接操作这个字典而不影响主数据结构的读取性能。面试如果被追问到这里能说出过期字典四个字已经比大多数候选人高一个段位了。3.2 过期键何时真正消失惰性删除 定期删除的组合拳设置过期时间之后问题来了过期时间到了键会立刻从内存中消失吗答案是不会立即消失。Redis的过期删除采用两种策略配合策略一惰性删除Lazy Delete每次通过命令访问key时Redis会顺带检查它是否已经过期。如果过期先删除再返回键不存在的结果。这个检查发生在lookupKeyRead这类底层函数里所以不管你执行GET、TTL还是EXPIRE只要碰了过期键Redis就会顺手把它清掉。惰性删除的优点是对CPU几乎零额外开销只在真正访问时做一次比较。缺点也很明显如果一个过期键之后再也没有被访问它就永远赖在内存里不走了。冷门数据量大时内存会被这些活着的僵尸键慢慢填满。策略二定期删除Active Delete为了解决上面那个问题Redis的后台会周期性执行一段逻辑随机抽取一批设置了过期时间的键检查并删除其中已经过期的。默认每100毫秒跑一次每次抽查一定数量默认是20个如果其中有超过25%的键已过期就继续多抽直到比例降下来。这套策略的巧妙之处在于它不是全库扫描那样太慢而是类似抽样巡检——既保证了过期键不会无限堆积又避免了单次清理由过多键带来的阻塞。这两套机制一快一慢一被动一主动合起来就是Redis过期删除的全部逻辑。面试官如果继续追问那惰性删除 定期删除就够了吗如果内存还是不够怎么办这里就自然衔接到内存淘汰策略eviction policy了——当内存达到maxmemory上限时Redis会通过maxmemory-policy配置决定驱逐哪些键这个虽然严格来说不是过期键删除但在面试里经常被放在一起问。3.3 一个容易忽视的副作用删除不是瞬时的TTL存在误差结合上面的机制有个实战中很常见的现象设置过期时间60秒但在第60秒后、后台定期删除还没扫到来之前键依然占着内存。此时你用TTL查可能返回一个很小的正数或0但实际GET这个key却有可能仍然返回旧值也可能返回nil两种都可能。这种过期时间到了但键还没物理消失的现象理解原理后就不慌了。尤其是做缓存设计时不能假定过期时间一到数据立即不可用。如果业务对时效性要求极高比如抢购状态的库存标记光靠Redis过期是不够的必须在上层业务逻辑再做一次时间校验。4. 生产环境踩坑实录那些看似没问题的过期设置4.1 坑一重建缓存时忘记重设过期时间最常见、影响也最隐蔽的坑我在代码评审里见过至少五六次。长这样// 获取缓存 String value redis.get(key); if (value null) { // 缓存不存在查数据库 value loadFromDB(); // 写回缓存 redis.set(key, value); // 忘记调用 expire(key, 3600) }如果这段代码运行一次缓存值是写进去了但EXPIRE忘记调这个key就永久有效。下次数据库里的内容改了Redis里还是老数据而且永远不会自动失效。轻则数据不一致重则用户看到脏数据投诉。解决方案就是前文提到的写成一步redis.set(key, value, 3600); // 各语言客户端基本都有带过期时间的set重载或者用命令SET key value EX 3600我个人习惯是哪怕这个场景本来想永久缓存也尽量给一个足够长的时间比如30天让系统有自愈能力。因为永久有效本身往往意味着永远记得去清理而对绝大多数业务系统来说没有人记得。4.2 坑二大量键同时过期导致Redis变慢有次线上服务在整点时段出现周期性的小幅超时查了一圈最后定位到原因凌晨0点有批量任务把一批活动页缓存过期时间统一设成了6小时后刷新。于是每个小时整点整点地集中失效。问题不在于删除本身而在于定期删除策略的触发机制当抽样中发现过期比例高时Redis会连续多轮执行删除逻辑。由于Redis是单线程的这个删除过程占用主线程执行时间命令响应就会变慢。解决方案有三板斧过期时间加随机偏移。比如基本超时3600秒再加一个0~300的随机数让键的过期时刻散开。把缓存预热提前。高并发的活动页不要等缓存真正过期后再回源数据库而是提前几分钟主动刷新。拆分key粒度。不要把整页数据塞进一个key拆成多个段各自带不同的过期时间。在面试里能说出大量键同时过期会触发定期删除连续执行导致Redis卡顿并且给出过期时间加随机偏移的解法是明显加分项。4.3 坑三把EXPIRE用在错误的数据类型上EXPIRE可以作用于所有数据类型包括List、Set、Hash和ZSet。但注意它作用于整个键不是单个元素。有个经典误用往List里连续推入多条消息想让每条消息单独在5分钟后删除于是每条都执行EXPIRE listKey 300。结果第一条执行后整个List被设了5分钟超时第二条执行时又把整个List的超时重置为5分钟。最后导致List里所有元素无论如何都在最后一条消息写入后的5分钟被全部清掉。如果需求真的是每个元素独立过期Redis原生的List/Hash都做不到得换设计每个元素用一个独立的String键存命名带唯一标识各自设置过期时间。或者引入定时任务定期扫描清理。面试的时候如果面试官问Redis的过期能作用在Hash里的field上吗答案是不能——这个问题看似简单但很多写了两年Redis的人都会答错。4.4 坑四主从复制与AOF持久化下的过期键还有个进阶知识点也经常被当作压轴题。在Redis主从架构中过期键的删除以主节点为准。主节点删除一个过期键时会向从节点发送一条DEL命令让从节点也删掉。如果客户端直接读从节点可能读到主节点已经删除但还没同步过来的过期数据——所以从节点的读请求最好也要做业务层的时间校验。在AOF持久化场景下过期键的删除不会直接改写AOF里的原值而是追加一条DEL命令。在RDB快照场景下生成快照时已经过期的键不会写入但生成快照的过程中恰好过期的键可能被写进去——加载快照时这些键又复活一小段时间直到惰性删除或定期删除处理掉。这些机制不用全背但脑子里要有过期键的删除在主从复制和持久化环境中不是瞬时而一致的这个意识。面试谈到部署架构时自然会用到。5. 面试官视角的追问清单从命令到原理到底怎么答不翻车5.1 高频追问一TTL返回-1和-2说明了什么这个追问几乎是必考的而且可以连环追TTL返回-1键存在但没设置过期时间此时执行PERSIST返回0因为本来就没有过期时间可移除。TTL返回-2键不存在。要小心的是它可能是真的不存在也可能是之前存在但刚刚过期被清掉了。只看TTL结果无法区分这两种情况必要时得结合业务日志判断。如果候选人主动补充返回-1意味着永久有效可以用PERSIST但不是它触发的面试官会认为你不仅知道命令还知道命令之间的边界。5.2 高频追问二过期键一定会被定期删除清理掉吗答案是不一定。定期删除只是抽样总有漏网之鱼。但Redis还有内存淘汰策略eviction作为最后一道防线。当Redis内存达到maxmemory上限时会按照maxmemory-policy清理键常见几种策略含义适用场景noeviction不淘汰写入直接报错内存足够大、严禁丢数据的场景allkeys-lru从所有键中淘汰最近最少使用的纯缓存场景volatile-lru仅从设置了过期时间的键里淘汰最近最少使用有部分键需要长期保留allkeys-random随机淘汰所有键数据访问无规律的缓存volatile-random仅从设置了过期时间的键里随机淘汰不太常用volatile-ttl优先淘汰剩余存活时间最短的键希望快死的先死注意volatile-lru这类策略要求键必须先设置过期时间否则该键不会进入淘汰候选池。所以给键设置过期时间还有一层隐藏意义——它给了Redis内存淘汰机制一个可以被优先淘汰的标记。在内存压力大的缓存系统中所有缓存键都应设置过期时间不只是为了业务上自动失效也为了让LRU淘汰策略有操作空间。5.3 高频追问三为什么有定期删除还要内存淘汰这俩解决的问题不同。定期删除解决的是过期键占着内存不放的问题内存淘汰解决的是内存容量到达上限需要腾空间给新数据的问题。哪怕所有键都没设置过期时间只要写入速度大于内存清理速度同样会触发淘汰。过期时间本身不等于内存保护伞。5.4 高频追问四一个键的过期时间被覆盖后之前的过期时间还有效吗分两种情况对已存在的键执行EXPIRE新的过期时间会覆盖旧的TTL从这次执行开始重新倒计时。对已存在的键执行SET不附带过期参数默认会清除过期时间等价于PERSIST这就是为什么SET key newValue会让原本会过期的键变成永久键。这个点很阴险很多人不知道。如果你更新一个缓存值时想保留原有过期时间必须重新用SET ... EX seconds。顺带一提GETSET写入新值并返回旧值同样会清除过期时间使用时要注意。5.5 面试答题模板怎么组织一段满分的回答如果面试官问如何设置键的过期时间和永久有效我建议按下面这个层次回答先直接给命令设置过期用EXPIRE key seconds或SET key value EX seconds永久有效要么不设过期要么对已有过期时间的键用PERSIST查看用TTL。补一个细节SET 过期参数是原子的能避免写入成功但过期没设上的隐患PERSIST只对已设置过期的键有意义返回0代表移除失败。再拔高一层过期时间存在过期字典里Redis通过惰性删除定期删除配合清理所以过期不等于立即消失。最后给一个业务案例曾遇到过批量键同时过期导致Redis周期卡顿后来通过过期时间加随机偏移解决。这个回答路径从命令到原理再到实战逻辑完整基本能cover这道题的绝大部分追问。6. 进阶实践业务系统里三天两头用到的过期时间设计6.1 验证码和登录态短过期时间 防抖短信验证码普遍设置5分钟过期。这里容易踩的坑是用户一分钟内连续请求多次每次都生成新验证码并重新设过期时间。攻击者可以不断刷新导致旧验证码永远有效因为每次都被重置。我的做法是同一个手机号在60秒内禁止重新发送令牌存Redis时用SETNX配合过期时间实现防抖SET sms:limit:13800138000 1 EX 60 NX如果返回nil说明60秒内已经发过一次直接拒绝。这套逻辑比在应用层加分布式锁简单得多而且天然带超时自愈。6.2 限流计数器滑动窗口别用错过期时间常用的固定窗口限流是INCR一个key第一次INCR后设置过期时间为窗口长度。比如1分钟限100次INCR rate:user:9527 EXPIRE rate:user:9527 60这种做法有个漏洞如果INCR返回1之后、EXPIRE执行之前进程崩溃这个key就永久存在计数永远不归零。但换成原子操作INCR rate:user:9527 EXPIRE rate:user:9527 60注意这两个命令本身不是原子的。稳妥做法是用Lualocal c redis.call(incr, KEYS[1]) if c 1 then redis.call(expire, KEYS[1], ARGV[1]) end return c这里有个更深的细节如果每次INCR都重置过期时间为60秒那么在高频访问下这个key可能一直续命窗口永远不会滑过去等于没限流。所以正确逻辑是仅当计数器第一次创建即INCR结果等于1时才设过期时间。这也是为什么上面的Lua里用if c 1判断——这个细节比单纯会写INCR更能体现对Redis语义的掌握。6.3 数据回源的保护缓存穿透时的空值缓存当查询数据库没有结果时如果什么都不缓存下一次同样请求还会打穿到数据库。常规做法是缓存一个空值或特殊标记并设置一个相对较短的过期时间比如3~5分钟在这期间同样key的请求直接命中空缓存不再访问数据库。SET cache:user:9527 null EX 180这个场景下过期时间的设计原则是短而有效——太短起不到拦截效果太长会导致真实数据恢复后客户端依然读到空值。一般建议在3~5分钟同时配一个后台任务一旦数据落库立即主动删掉空缓存。6.4 热点数据的防击穿过期时间前主动续期缓存最常见的模式是读DB → 写Redis → 设过期时间到期后再回源。但如果一个key的访问量极大到期瞬间所有请求同时打到DB就是缓存击穿。业界标准的解决思路不要让所有请求都等过期时间到了才回源而是搞一个后台定时任务比如在过期时间到达前的1/3时刻检查一下key是否即将过期如果是则提前主动刷新。这里的刷新要重新查DB、重写缓存、重设过期时间。用代码伪代码表示// 后台任务每30秒执行一次 for (String hotKey : hotKeys) { long ttl redis.ttl(hotKey); if (ttl 0 ttl 60) { String freshData loadFromDB(hotKey); redis.set(hotKey, freshData, 3600); } }这种TTL接近0就续期的模式比布隆过滤器、互斥锁都要轻量尤其适合读多写少、单key热点极高的场景。6.5 过期时间与数据一致性延迟双删的补充经典的数据一致性方案延迟双删里过期时间也扮演角色。更新数据库后先删Redis缓存过几百毫秒再删一次防止第一次删除后到第二次删除前有旧数据被并发请求写回缓存。但如果压根不用删除而是采用更新时给缓存设置一个很短的过期时间其实也能变相保证一致性。比如写入数据后给缓存key设置EXPIRE 5让它在5秒后自动失效。这比双删少了一次删除的强一致操作更简单但存在最多5秒的短暂不一致窗口——能否接受取决于业务。这是设计取舍的问题没有银弹只有适合场景的方案。面试时能说出来不同一致性级别对应不同的过期时间设计就比只背命令强太多。7. 借助Redis可视化工具与命令自查日常排障中判断过期键状态的实操方法7.1 命令行自查三板斧排查生产环境问题时不要一上来就翻代码。先用Redis命令行把状态摸清楚第一步用DBSIZE看当前库有多少键如果数量异常膨胀优先怀疑是否有大量键没设过期时间。第二步用SCAN配合TTL写一条简单的脚本找出所有TTL为-1的键redis-cli --scan --pattern * | xargs -L 1000 redis-cli ttl | grep -v [0-9-]*-1如果你想更精确地列出所有永久键的key名可以写一段简单的Lua或Python脚本逐批SCAN并收集TTL为-1的key。一个可用的小脚本思路如下for key in $(redis-cli --scan --pattern cache:*); do ttl$(redis-cli ttl $key) if [ $ttl -eq -1 ]; then echo $key (永久) fi done注意别在线上大库直接跑这么暴力的脚本SCAN虽然不阻塞但xargs起的子进程太多会占满CPU。稳妥做法是先采样一批比如只扫cache:*前缀且限制数量。第三步用INFO命令查看内存和淘汰情况redis-cli INFO memory redis-cli INFO stats重点关注used_memory、evicted_keys被淘汰的键数和expired_keys因过期被删除的键数。如果expired_keys增长很快说明过期键确实在被清理如果used_memory持续高位但evicted_keys为0可能是maxmemory-policy配置不对或者根本没有设置maxmemory。7.2 可视化工具里怎么快速定位永久键市面上常见的Redis可视化工具RedisInsight、Another Redis Desktop Manager等基本都能浏览key列表并显示TTL列。排查哪些键没有设置过期时间直接按TTL列排序值为-1的key全部排在前面/后面一目了然。不过可视化工具在大键多、生产环境直连时容易卡顿我一般只在低峰期或本地调试环境用。线上排查还是优先走命令行的SCAN方案避免长连接和GUI渲染对Redis主线程造成额外压力。7.3 从自查到监控给过期键建立常态化的体检机制光靠一次排查不够。比较推荐的做法是在监控面板上增加两条自定义告警当expired_keys在5分钟内增长异常比如超过某个阈值时说明可能有大量键集中过期需要人工关注缓存回源压力。当evicted_keys持续大于0时说明已经触发了内存淘汰大量缓存数据可能被无差别清理下游DB会迎来一波流量尖峰。这两条告警配合起来基本能在大量键同时过期和缓存失效风暴发生之前提前暴露风险。这是比单纯记命令更值钱的经验。8. 最后的实操心得三句话记住核心要点文章最后分享几个我实践中反复磕碰之后沉淀下来的心得不需要背但建议抄进项目文档里。第一句**所有缓存键都必须设置过期时间哪怕给个足够大的值。**不是为了业务上的自动清理而是为了给Redis内存淘汰策略留出操作空间。别忘了volatile-lru只认带过期时间的键。第二句**设置过期时间和写入值要保证原子性。**能一条SET ... EX解决的绝不用SETEXPIRE两条命令非要用INCR这种不支持带过期参数的场景就上Lua或先判断再设过期。第三句**过期不等于立即消失删除了才算。**理解了惰性删除和定期删除你就不会再被TTL到了为什么还能读到值为什么Redis偶尔卡顿这种问题困扰。设计缓存时业务侧永远要假设最坏情况下过期键还会多存活一小段时间。另外如果正处于面试备战阶段建议把本文第二节的表格打印出来贴在屏幕边再把第5.5节的回答模板用自己话复述三遍。面试官问到如何设置键的过期时间和永久有效时能做到从命令到原理再到实战案例完整输出这一题基本稳了。