【Redis】过期键删除策略，LRU和LFU在redis中的实现，缓存与数据库双写一致性问题，go案例

一、Redis 中的过期键删除策略有哪些？

采用了 惰性删除 和 定期删除 两种策略处理过期键：

1. 惰性删除（Lazy Deletion）

机制：只有在访问 key 时才检查是否过期，如果已过期则立刻删除。
优点：对 CPU 资源最友好，只在必要时才处理。
缺点：若 key 过期但始终未被访问，则不会释放内存，容易造成空间浪费。

Redis 实现方式：每次访问前调用 expireIfNeeded() 判断是否过期，若已过期，Redis 4.0 起还支持 lazyfree_lazy_expire 控制是否异步删除。

2. 定期删除（Periodic Deletion）

机制：Redis 每秒默认执行 10 次定期删除 ，每次从过期字典中随机抽取 20 个 key 检查。
流程：
1. 抽 20 个 key，删除其中过期的；
2. 若这 20 个里有超过 25%（即 5 个）过期，则继续循环；
3. 每次循环有时间上限，默认 不超过 25ms，防止阻塞主线程。
优点：相较惰性删除，能主动清理部分过期 key，提升内存利用率；
缺点：受限于检查频率和时间，可能存在部分过期 key 无法及时清理的问题。

二、为什么不用定时删除？

定时删除（即为每个 key 单独设置定时器，到期立即删除）并未被 Redis 实际采用。

优点：能最及时地释放内存；
缺点：大量 key 会引入大量定时任务 ，极大增加 CPU 开销，尤其在过期 key 较多时，会严重影响 Redis 的性能和响应时间。

三、总结：

Redis 的过期键清除策略采用了 惰性删除 + 定期删除的组合策略 ，在保证较低 CPU 开销 的同时，尽可能释放内存空间。

惰性删除 是只在访问key的时候检查是否过期；

定期删除 定时进行部分key的过期检查；

Redis 放弃了定时删除，是因为对每个key单独计时过期删除，会大大增加cpu负担

一、什么是 LRU 算法？

LRU，全称 Least Recently Used ，即「最近最少使用」策略，用于在内存满时淘汰最久未被访问的键。

传统 LRU 的实现方式：

通常使用双向链表 + 哈希表实现；
每次访问某个 key，就将其移动到链表头部；
淘汰时，从链表尾部删除最旧访问的 key。

传统 LRU 的问题：

维护链表需要额外的内存；
每次访问都要更新链表结构，频繁的链表操作会带来性能瓶颈。

二、Redis 如何实现 LRU？

Redis 没有使用传统 LRU，而是实现了近似 LRU，采用"随机采样 + 时间戳"方式。

实现细节：

Redis 为每个键的对象结构添加了 lru 字段，记录其最近访问时间（非绝对时间，是一个全局逻辑时钟）。
Redis 每次进行内存淘汰时，并不会遍历所有键 ，而是从所有键中随机采样若干个（默认 5 个），然后挑出其中访问最久远的键淘汰。
这个采样数量可通过参数 maxmemory-samples 配置。

优点：

无需维护全局链表，节省空间；
不需要每次访问都做链表操作，大幅提高性能；
适用于高性能场景的内存淘汰。

缺点：

由于是近似 LRU，并非全局最久未使用的键一定会被淘汰，存在一定误差；
可能出现缓存污染问题：某些键被短时间大量访问后遗留在内存中，却很少被再次使用。

三、什么是 LFU 算法？（Redis 4.0+ 引入）

LFU，全称 Least Frequently Used ，即「最不常访问」策略。用于淘汰访问次数最少的键，更能避免短期热点带来的缓存污染。

Redis 中 LFU 的实现方式：

Redis 在每个键中增加了一个 访问频率计数器；
每次访问某个 key，会更新其计数；
内存淘汰时，采用类似于近似 LRU 的方式 ------ 随机采样几个 key，选择访问频率最少的淘汰。

优点：

解决了 LRU 中"只访问一次却常驻内存"的问题；
更适合处理热点数据与长尾数据共存的缓存场景。

特性	Redis 中的 LRU	Redis 中的 LFU
全称	Least Recently Used	Least Frequently Used
淘汰依据	最近一次访问时间	被访问的频率
实现方式	每个 key 保存时间戳 + 随机采样	每个 key 保存访问次数 + 随机采样
淘汰方式	随机采样若干 key，淘汰其中最久未访问的	随机采样若干 key，淘汰其中访问最少的
优点	高效节省内存	能减少缓存污染
典型场景	访问时间分布均匀	存在热点和冷数据

一、四种缓存一致性方案对比表格

编号	操作顺序	是否推荐	问题说明
1	先更新数据库 → 后更新缓存	否	并发更新可能将旧值写入缓存，导致脏数据
2	先更新缓存 → 后更新数据库	否	缓存更新成功但数据库失败，导致数据不一致
3	先删除缓存 → 后更新数据库	是	可避免脏数据写入缓存，但可能存在缓存空窗期
4	先更新数据库 → 后删除缓存	是	若删除缓存失败，可能导致脏缓存，可使用"延迟双删"策略优化

二、推荐方案三：先删除缓存 → 后更新数据库

复制代码

时间线场景：
T1：请求A准备写操作，删除缓存
T2：请求B查询，发现缓存 miss（被 A 删除了）
T3：请求B 回源数据库，读取旧数据（因为 A 还没更新 DB）
T4：请求B 将旧数据写入缓存
T5：请求A 将新数据写入数据库

问题解决思路：

删除缓存后写数据库，防止更新时缓存被覆盖
并发下的读写覆盖问题，需要加写操作保护措施：例如分布式锁 、队列、串行化写
可使用分布式锁优化并发场景

Go 语言实现（含分布式锁）：

依赖（Redlock 实现分布式锁）：

使用 github.com/bsm/redislock：

bash 复制代码

go get github.com/bsm/redislock

完整代码：

go 复制代码

package main

import (
    "context"
    "fmt"
    "log"
    "time"

    "github.com/bsm/redislock"
    "github.com/redis/go-redis/v9"
)

var (
    ctx        = context.Background()
    rdb        = redis.NewClient(&redis.Options{Addr: "localhost:6379"})
    locker     = redislock.New(rdb)
)

type UserProfile struct {
    ID   int64
    Name string
}

// 模拟数据库操作
func updateUserInDB(userID int64, newData *UserProfile) error {
    fmt.Printf("DB Updated: userID=%d, data=%+v\n", userID, newData)
    return nil
}

func UpdateUserWithLock(userID int64, newData *UserProfile) error {
    lockKey := fmt.Sprintf("lock:user:%d", userID)
    lock, err := locker.Obtain(ctx, lockKey, 5*time.Second, nil)
    if err != nil {
        return fmt.Errorf("failed to obtain lock: %w", err)
    }
    defer lock.Release(ctx)

    // 删除缓存
    cacheKey := fmt.Sprintf("cache:user:%d", userID)
    if err := rdb.Del(ctx, cacheKey).Err(); err != nil {
        log.Printf("failed to delete cache: %v", err)
    }

    // 更新数据库
    if err := updateUserInDB(userID, newData); err != nil {
        return fmt.Errorf("failed to update db: %w", err)
    }

    return nil
}

三、推荐方案四：先更新数据库 → 后删除缓存（延迟双删）

复制代码

时间线场景：
T1：请求A准备更新，先写数据库
T2：请求B 查询缓存，发现存在旧值
T3：请求A 删除缓存（第一次）
T4：请求B 读取旧缓存数据并返回
T5：请求B 之后把旧数据重新写入缓存（或未写入）
T6：请求A 延迟100ms后再次删除缓存

问题解决思路：

删除缓存失败会导致脏缓存
可采用"延迟双删策略"：更新完数据库后立即删一次缓存，并延迟一段时间再删一次

Go 语言实现：

go 复制代码

package main

import (
    "context"
    "fmt"
    "log"
    "time"

    "github.com/redis/go-redis/v9"
)

var (
    ctx = context.Background()
    rdb = redis.NewClient(&redis.Options{Addr: "localhost:6379"})
)

type UserProfile struct {
    ID   int64
    Name string
}

// 模拟数据库操作
func updateUserInDB(userID int64, newData *UserProfile) error {
    fmt.Printf("DB Updated: userID=%d, data=%+v\n", userID, newData)
    return nil
}

func UpdateUserWithDelayDelete(userID int64, newData *UserProfile) error {
    // 更新数据库
    if err := updateUserInDB(userID, newData); err != nil {
        return fmt.Errorf("failed to update db: %w", err)
    }

    // 删除缓存
    cacheKey := fmt.Sprintf("cache:user:%d", userID)
    if err := rdb.Del(ctx, cacheKey).Err(); err != nil {
        log.Printf("delete cache failed: %v", err)
    }

    // 延迟双删（异步）
    go func() {
        time.Sleep(100 * time.Millisecond)
        if err := rdb.Del(ctx, cacheKey).Err(); err != nil {
            log.Printf("delayed delete failed: %v", err)
        }
    }()

    return nil
}

四、总结

场景	推荐方案	优点	需注意问题与优化点
一般中小型项目	方案三	实现简单、延迟可控	可用 Redis 锁优化
高频写/对一致性敏感	方案四	数据库操作主导、双删更稳健	需延迟双删、监控缓存删除是否成功
高并发写入场景	方案三+锁	防止并发缓存回写	Redlock 实现需健壮

https://github.com/0voice