【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：

go get github.com/bsm/redislock

完整代码：

package mainimport ("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   int64Name 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 语言实现：

package mainimport ("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   int64Name 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 实现需健壮