你有没有遇到过这种情况：Redis 用着用着，内存突然满了，但系统还在拼命往里塞数据？这时候 Redis 并不会崩溃，而是悄悄地“清人腾位”。那它凭什么决定“谁走谁留”？
今天，小米就带你认识 Redis 背后的那位老管家——LRU 算法，用一个仓库的故事，把这套内存回收机制彻底讲清楚。
故事从一个被塞爆的仓库开始
我是小米，今年 31 岁，写代码第 10 年。那天我正坐在工位上，刚泡好一杯咖啡，监控突然红了一片：
Redis used_memory 达到 maxmemory
QPS 开始抖
延迟飙升
我心里一紧，第一反应是：“完了，是不是 Redis 要炸了？”
但很快我发现一个奇怪的现象：Redis没有挂，而是慢慢恢复了平稳。
我突然意识到一件事：Redis，在自己偷偷“扔东西”。这就像一个仓库，被塞满了，但仓库管理员并没有锁门不干活，而是开始把“没用的旧货”往外丢。
这个管理员，名字叫LRU。
Redis 的内存不是无限的
在 Redis 的世界里，有一条铁律：内存是有限的，优先级是残酷的。
你在配置文件里通常会看到这两行：
maxmemory 4gb
maxmemory-policy allkeys-lru
这两行翻译就是：
- Redis 最多只能用 4GB 内存
- 如果内存满了，就按LRU 算法来淘汰数据
于是问题来了：什么是 LRU？
