EXPIRE 怎样避免刷新 TTL
Redis 的 EXPIRE key seconds 默认会把键的当前 TTL 改成新的秒数。如果业务要求“第一次设置后不再刷新”,最直接的写法是给 EXPIRE 加上 NX;如果只允许在已有 TTL 的键上更新,则使用 XX。需要控制方向时,LT 只接受更短的新 TTL,GT 只接受更长的新 TTL。
官方地址:https://redis.io/docs/latest/commands/expire/
把“避免刷新 TTL”拆成明确规则:只首次设置用NX,只处理已有过期时间用XX,只缩短用LT,只延长用GT。命令返回1才表示本次真的改了过期时间,返回0表示条件没有满足。
先看懂 EXPIRE 为什么会刷新 TTL
无条件的 EXPIRE cache:user:42 300 不会比较旧 TTL,而是直接尝试把键的过期时间设为 300 秒。缓存命中后重复执行这条命令,就可能把本来只剩 20 秒的键重新变成 300 秒,形成“访问越多,过期越晚”的滑动效果。
| 业务规则 | 命令形式 | 条件不满足时 |
|---|---|---|
| 只在没有 TTL 时首次设置 | EXPIRE key seconds NX | 已有 TTL 或键不存在时返回 0 |
| 只更新已经有 TTL 的键 | EXPIRE key seconds XX | 没有 TTL 或键不存在时返回 0 |
| 只把过期时间变短 | EXPIRE key seconds LT | 新 TTL 不更短时返回 0 |
| 只把过期时间变长 | EXPIRE key seconds GT | 新 TTL 不更长时返回 0 |

这些条件参数只能四选一,不能把 NX 和 LT 叠加成一个命令。实际选择前,先明确你是在防止重复续期,还是在限制 TTL 变化方向。
用 NX、XX、LT、GT 限制更新范围
“只首次设置”通常对应缓存填充或一次性保护窗口。下面的命令会在键没有 TTL 时设置 300 秒;如果键已经有 TTL,即使它只剩 5 秒,也不会被刷新。
# NX 只在当前键没有过期时间时设置,避免重复访问把 TTL 重新拉长 redis-cli EXPIRE cache:user:42 300 NX # XX 只处理已经存在过期时间的键,不给永久键凭空增加 TTL redis-cli EXPIRE cache:user:42 120 XX # LT 只接受更短的新 TTL,适合收紧缓存保留窗口 redis-cli EXPIRE cache:user:42 60 LT # GT 只接受更长的新 TTL,适合延长仍在有效期内的缓存 redis-cli EXPIRE cache:user:42 600 GT
NX 关注的是“有没有过期时间”,XX 关注的是“已经有过期时间”;LT 和 GT 关注的是新旧过期时间的方向。Redis 文档把没有 TTL 的键视作非 volatile 键,比较 GT 或 LT 时不要把它误解成一个普通的剩余秒数。
条件版本的 EXPIRE 自 Redis 7.0 起支持 NX、XX、GT、LT。如果客户端报参数错误,应先确认服务端版本与客户端命令封装是否匹配,而不是退回到无条件刷新。
用返回值和 TTL 判断是否真的改动
EXPIRE 返回整数 1 或 0。返回 1 表示过期时间已设置;返回 0 可能意味着键不存在,也可能是条件参数阻止了更新。要区分当前状态,可以紧接着读取 TTL:-1 表示键存在但没有过期时间,-2 表示键不存在。
# 先读取剩余 TTL,避免把条件失败误判为网络故障 redis-cli TTL cache:user:42 # 只有返回 1,才把“TTL 策略已更新”写入业务日志 redis-cli EXPIRE cache:user:42 300 NX # 用 TTL 复核键仍存在、且当前确实带有过期时间 redis-cli TTL cache:user:42
这里的复核是业务判断,不是让调用方通过“先读 TTL、再决定是否写入”来模拟条件更新。真正的条件应交给带 NX、XX、LT 或 GT 的单条命令完成,避免并发客户端之间出现先读后写的竞态。
覆盖写入时怎样保住 TTL
避免 EXPIRE 自己刷新 TTL 还不够。如果后续使用普通 SET 覆盖字符串值,Redis 会清除该键原有的过期时间。需要在更新值的同时保留旧 TTL 时,应使用 SET ... KEEPTTL;这个规则与 EXPIRE NX 是两个不同层面的保护。
# 普通 SET 会覆盖值,并清除原有 TTL;不要用于需要保留过期时间的更新
redis-cli SET cache:user:42 '{"name":"Ada"}'
# KEEPTTL 在替换字符串值时保留原有过期时间
redis-cli SET cache:user:42 '{"name":"Grace"}' KEEPTTL
# 如果更新时还要求键必须已存在,可组合 XX 与 KEEPTTL
redis-cli SET cache:user:42 '{"name":"Lin"}' XX KEEPTTL

如果键不是字符串类型,SET 本身就不适用;列表、哈希等数据结构的修改命令通常不会因为增量修改而清除 TTL,但任何会替换整个键值的命令都应单独核对过期语义。
落地选择清单
- 目标是“只设置一次”:使用
EXPIRE key seconds NX。 - 目标是“只给临时键调整”:使用
XX,避免给永久键误加 TTL。 - 目标是“不能延长”:使用
LT;目标是“不能缩短”:使用GT。 - 更新字符串值但不能丢 TTL:使用
SET ... KEEPTTL,不要把它和EXPIRE的条件混为一谈。 - 把返回值
0当作条件未满足处理,再通过TTL区分键不存在和无过期时间。
相关问题:
- EXPIRE NX 能和 XX 一起使用吗?不能。它们是互斥条件,分别表达没有 TTL 和已有 TTL 两种相反前提。
- 为什么 EXPIRE 返回 0?键可能不存在,也可能不满足 NX、XX、LT 或 GT 的条件;读取 TTL 可以帮助区分当前状态。
- 只用 EXPIRE NX 能防止 SET 清除 TTL 吗?不能。覆盖字符串值时还要使用
SET ... KEEPTTL,因为这是值写入命令的过期处理规则。
总结来说,避免刷新 TTL 不是把过期时间固定成某个数字,而是把更新条件写进命令:首次设置用 NX,按方向控制用 LT/GT,覆盖值时用 KEEPTTL 保住已有策略。
WATCH 怎样处理事务竞争重试
- 上一篇
- WATCH 怎样处理事务竞争重试
- 下一篇
- 淘汰策略 怎样选择 volatile 或 allkeys
-
- 数据库 · Redis | 1小时前 |
- 事务队列 怎样区分排队错误与执行错误
- 431浏览 收藏
-
- 数据库 · Redis | 1小时前 |
- 淘汰策略 怎样选择 volatile 或 allkeys
- 464浏览 收藏
-
- 数据库 · Redis | 1小时前 |
- WATCH 怎样处理事务竞争重试
- 143浏览 收藏
-
- 数据库 · Redis | 1小时前 | Redis ·
- 多个 consumer group 怎样分别重放事件
- 442浏览 收藏
-
- 数据库 · Redis | 1小时前 |
- MAXLEN 怎样限制 Stream 保留长度
- 376浏览 收藏
-
- 数据库 · Redis | 1小时前 |
- XAUTOCLAIM 怎样自动转移超时消息
- 252浏览 收藏
-
- 数据库 · Redis | 1小时前 | Redis · 消息队列 · Stream · 消费者组 Redis Stream PEL XCLAIM
- XCLAIM 怎样接管失联消费者消息
- 261浏览 收藏
-
- 数据库 · Redis | 1小时前 |
- XPENDING 怎样找出长期未确认消息
- 159浏览 收藏
-
- 数据库 · Redis | 1小时前 |
- XACK 怎样清理待处理消息
- 347浏览 收藏
-
- 数据库 · Redis | 1小时前 |
- XREADGROUP 怎样分摊 Stream 消息
- 158浏览 收藏
-
- 数据库 · Redis | 12小时前 |
- Redis SINTERCARD 怎样只计算集合交集数量
- 393浏览 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 485次学习
-
- PubMedQA
- 深入了解PubMedQA生物医学问答数据集,涵盖其核心功能、使用方法及在临床决策、药物研发等场景的应用,助力提升NLP模型性能。
- 684次使用
-
- H2O EvalGPT
- H2O EvalGPT是H2O.ai推出的开源LLM评估平台,提供详细的大模型性能排行榜、行业特定基准测试及A/B测试功能,助您快速选择最适合项目的高性能大语言模型。
- 699次使用
-
- LMArena
- LMArena是加州大学伯克利分校推出的AI模型匿名评测平台。通过盲测投票机制,用户可对比不同大模型回答并生成实时排行榜,助力开发者优化模型及用户选择最佳AI工具。
- 749次使用
-
- HELM
- 深入了解斯坦福推出的HELM(Holistic Evaluation of Language Models)大模型评测体系。本文解析其核心功能、安装配置步骤及应用场景,涵盖准确性、公平性、鲁棒性等多维度指标,助力开发者全面优化语言模型性能。
- 714次使用
-
- MMBench
- MMBench是由上海人工智能实验室等机构联合推出的多模态基准测试平台,提供细粒度能力评估、大规模数据集及VLMEvalKit工具。本文详细介绍其核心功能、安装使用方法及应用场景,助力开发者全面评估多模态模型性能。
- 551次使用
-
- Go与Redis实现分布式互斥锁和红锁
- 2022-12-22 117浏览
-
- Go+Redis实现延迟队列实操
- 2023-02-23 426浏览
-
- 一文搞懂Go语言操作Redis的方法
- 2023-01-07 171浏览
-
- Golang分布式应用之Redis示例详解
- 2023-01-07 113浏览
-
- Go Redis客户端使用的两种对比
- 2022-12-30 195浏览

