Redis中如何标记key过期但不实际从数据库删除该key？

存在完全可行的落地方案，不需要额外部署独立数据库或额外Redis实例，仅靠业务层逻辑配合现有Redis即可实现「标记key过期触发更新、生产方故障时旧数据持续兜底」的效果，核心是避开Redis原生的过期删除机制，自行在业务层实现逻辑过期判断。

方案1：逻辑过期字段嵌入（工业界最常用，无额外key开销） #

不要给存储真实业务数据的key设置Redis原生TTL，让key永久常驻内存，只需要在存储的value结构中额外加入一个逻辑过期时间戳字段即可：

• 写入缓存时：将真实业务数据、计算好的逻辑过期时间（当前时间+预期缓存有效期）序列化后存入Redis，整个key不设置原生过期时间
• 读取缓存时：
  1. 取出value反序列化，对比当前时间和内置的逻辑过期时间
  2. 若未到过期时间，直接返回缓存中的业务数据
  3. 若已过逻辑过期时间，先直接把旧数据返回给客户端，同时通过异步线程/任务队列触发缓存更新逻辑：尝试访问数据生产方拉取最新数据，拉取成功则重新写入缓存、更新逻辑过期时间；如果拉取失败（生产方不可达、超时、报错），直接吞掉异常不做处理，旧数据会一直留在缓存中等待下次读请求触发重试更新。

这个方案的额外开销极低，每个key仅多占8字节左右的时间戳存储空间，不需要修改原有Redis部署，也不需要新增任何存储组件。

方案2：轻量标记key双写（无需修改原有业务数据结构） #

如果不想改动原有业务value的序列化结构，可以在同一个Redis实例中为每个业务key配套一个轻量的过期标记key，不需要额外部署服务：

• 存真实业务数据的key永久保存，不设TTL
• 配套的标记key（比如业务key为order:1001，标记key为order:1001:expire_flag）不存实际value，仅设置你需要的缓存有效期作为TTL
• 读取时先检查标记key是否存在：存在则说明缓存未过期，直接返回业务key的数据；标记key不存在则说明需要更新，同样先返回旧的业务数据，异步拉取最新数据，拉取成功后更新业务key、重置标记key的TTL，拉取失败则保留旧数据即可。

标记key仅做存在性判断，没有实际value存储，内存开销可以忽略，适合不方便修改原有缓存value结构的存量业务场景。

以逻辑过期方案为例，核心读写逻辑如下：

// 缓存写入方法
function setCache(bizKey, bizData, ttlSeconds) {
    cacheItem = {
        "data": bizData,
        "expireAt": currentUnixTimestamp() + ttlSeconds
    }
    // 关键：不设置Redis原生TTL，key永久保留
    redis.set(bizKey, JSON.stringify(cacheItem))
}

// 缓存读取方法
function getCache(bizKey) {
    rawCache = redis.get(bizKey)
    if (!rawCache) {
        // 缓存首次不存在的场景，可通过短互斥锁控制回源，避免缓存击穿
        return rebuildCacheFromSource(bizKey)
    }
    cacheItem = JSON.parse(rawCache)
    // 判断逻辑过期
    if (currentUnixTimestamp() > cacheItem.expireAt) {
        // 异步触发更新，不阻塞当前请求返回
        asyncExec(() -> {
            try {
                latestData = fetchFromDataProducer(bizKey)
                setCache(bizKey, latestData, DEFAULT_CACHE_TTL)
            } catch (Exception e) {
                // 回源失败直接忽略，旧数据持续保留兜底
                log.error("update cache failed, fallback to old data", e)
            }
        })
    }
    // 无论是否过期，优先返回已有数据兜底
    return cacheItem.data
}

• 不要尝试通过修改Redis配置、改写Redis源码的方式实现“过期不删”，Redis本身没有提供相关开关，这类改造成本极高且稳定性差，业务层实现逻辑过期的性价比最高
• 异步更新环节建议加10~30秒的短互斥锁，避免同一时间大量请求命中过期缓存时，重复回源打挂数据生产方
• 该方案属于异步更新模型，会存在极短的数据不一致窗口，适合可用性优先级高于强一致、需要故障兜底的缓存场景，和需求描述的匹配度极高。

内容的提问来源于stack exchange，提问作者CaptainDriftwood