呗老心眼极小1. 缓存淘汰问题是怎么冒出来的：两个真实场景
先说一个我早年间踩过的坑。当时给一个报表系统做数据层优化，把热数据放进了 Redis，内存配了 512MB。上线跑了两周一切正常，直到月底财务跑批量对账，内存突然被打满，Redis 开始疯狂换页，最终 OOM 崩了。我当时的第一个念头是"内存不够，加内存就完事了"，于是扩容到 2GB。结果三个月后同样的问题再次出现。
后来复盘时，我才意识到问题根本不在容量，而在于我根本没有定义"什么数据值得留在缓存里"。缓存空间永远是有限的，但访问模式是动态的。当缓存满了，到底淘汰谁、保留谁？这个决策策略，就是缓存淘汰算法。用错了策略，再大的内存也会被垃圾数据占满。
类似的问题在 MySQL 的 Buffer Pool 里也天天发生。InnoDB 从磁盘读数据页时，会先把页放到 Buffer Pool 里，这个缓冲池默认是 128MB（新版本默认值更大）。你把一张 10GB 的表全表扫描一遍，Buffer Pool 里就全是扫描过的数据页，真正高频访问的页反而被挤出去了。下一次查询热点数据，又要重新走磁盘，性能瞬间打回原形。
所以缓存淘汰算法要解决的核心问题永远是同一个：用有限的存储空间，尽可能提高命中率。而 LRU（Least Recently Used，最近最少使用）和 LFU（Least Frequently Used，最不经常使用）是其中应用最广、也最值得深入理解的两个算法。这篇文章我会先用图解把原理拆清楚，再给出完整的 Go 语言实现，最后聊聊实际工程里它们是怎么被改造成"可用版本"的。无论你是面试准备、还是要在自己的服务里手写缓存，这篇文章都能直接参考。
先把两个概念用一句话说清楚，方便后面展开：
- LRU：淘汰最久没被访问的数据。它假设"过去被访问过的数据，未来大概率还会被访问"，而且最近被访问的数据比很久以前被访问的数据更可能被再次访问。
- LFU：淘汰被访问次数最少的数据。它假设"被访问次数多的数据，未来也会被频繁访问"。
这两个假设听起来都很合理，但它们暗含的淘汰逻辑是相反的：LRU 看的是"时间维度"，LFU 看的是"频率维度"。理解这个差异，你就会知道为什么有些场景 LRU 表现优秀，换到另一个场景就一塌糊涂。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. LRU 图解与 Go 实现：哈希表加双向链表为什么是绝配
2.1 先图解 LRU 的结构设计
LRU 最经典的实现结构是 哈希表 + 双向链表。很多教程上来就丢代码，但从不解释"为什么非要用这两个结构组合"。我换个方式讲。
先给一个容量为 3 的缓存，依次访问数据 A、B、C，此时链表状态是：
code复制头 -> C -> B -> A -> 尾（尾端是最久没被访问的）
如果这时再访问一次 B，B 会被移动到头部：
code复制头 -> B -> C -> A -> 尾
如果继续访问 D，缓存满了，就需要淘汰尾部的 A：
code复制头 -> D -> B -> C -> 尾
整个过程就两件事：
- 访问一个已存在的 key：把它从链表里摘下来，放到链表头部（代表"最近刚用过"）。
- 插入一个新 key 且缓存已满：先删除链表尾部的节点，再把新节点放到链表头部。
这里有个关键点：链表的访问、删除、插入操作，如果是普通链表，找到对应节点得遍历，复杂度是 O(n)。但配上哈希表，情况完全变了——哈希表的 value 直接存链表节点的指针，这样链表的 find 可以做到 O(1)。而链表的摘除和头部插入也只需要调整几个指针，同样是 O(1)。一组合，整个 LRU 的读写复杂度都降到了 O(1)，这就是这个组合被称为"绝配"的原因。
我画一张简单的结构图，方便你对照代码理解：
code复制+----------------+ +------------+ +------------+
| hash map | | head | | tail |
| key -> *node | | (虚拟头) | | (虚拟尾) |
+----------------+ +------------+ +------------+
| "A" -> node1 | ---> | next: node1| <---> | prev: node3|
| "B" -> node2 | +------------+ +------------+
| "C" -> node3 | +------------+ +------------+
+----------------+ | node1 | <---> | node3 |
| key: "A" | | key: "C" |
| value: 1 | | value: 3 |
+------------+ +------------+
+------------+
| node2 |
| key: "B" |
| value: 2 |
+------------+
注意图里 head 和 tail 我用的是虚拟节点。这个设计不是强迫症，而是为了省掉大量"判断头尾为空"的分支逻辑。如果链表为空，普通实现里你要先判断 head 是否为 nil 才能决定怎么插入；有了虚拟头尾节点，所有插入删除都是同样的指针操作，代码会简洁不少。
2.2 Go 语言实现 LRU
直接上代码。我用 Go 标准库里的 container/list 来实现双向链表，因为它内部就是 list.Element 结构，MoveToFront、Remove 这些接口都封装好了，不用自己维护一堆指针。
go复制package lru
import (
"container/list"
"sync"
)
type Cache struct {
mu sync.Mutex
capacity int
items map[string]*list.Element
list *list.List
}
type entry struct {
key string
value interface{}
}
func NewCache(capacity int) *Cache {
if capacity <= 0 {
panic("capacity must be positive")
}
return &Cache{
capacity: capacity,
items: make(map[string]*list.Element, capacity),
list: list.New(),
}
}
func (c *Cache) Get(key string) (interface{}, bool) {
c.mu.Lock()
defer c.mu.Unlock()
if elem, ok := c.items[key]; ok {
// 访问了，就移到链表头部
c.list.MoveToFront(elem)
return elem.Value.(*entry).value, true
}
return nil, false
}
func (c *Cache) Set(key string, value interface{}) {
c.mu.Lock()
defer c.mu.Unlock()
if elem, ok := c.items[key]; ok {
// key 已存在：更新值并移到头部
elem.Value.(*entry).value = value
c.list.MoveToFront(elem)
return
}
newElem := c.list.PushFront(&entry{key: key, value: value})
c.items[key] = newElem
if c.list.Len() > c.capacity {
// 淘汰链表尾部的元素
tailElem := c.list.Back()
if tailElem != nil {
c.list.Remove(tailElem)
delete(c.items, tailElem.Value.(*entry).key)
}
}
}
这段代码有几处可以直接拿去用的工程细节：
- 加锁：我把
sync.Mutex直接放进 Cache 结构里了。实际场景中缓存会被并发访问，不加锁会出现 data race。如果你对性能有极端要求，可以改成分段锁或者分片，但这个版本在绝大多数并发量下已经够用。 - 删除 key 时要用 entry 里的 key：因为哈希表的 key 是字符串，链表的节点里只存了
*entry。淘汰时如果只拿到了tailElem，需要从entry.key往回拿到原始 key 才能delete(c.items, ...)。很多人第一次写的时候会卡在这。 - capacity 为 0 的防御：
NewCache里做了 panic。实际业务中 0 容量的缓存几乎没有意义，与其让它运行时报"永远淘汰所有数据"的诡异 bug，不如启动时就崩溃。
2.3 用一个小例子验证
写个简单的测试用例，感受下 LRU 的行为：
go复制package lru
import "testing"
func TestLRUBasic(t *testing.T) {
c := NewCache(3)
c.Set("A", 1)
c.Set("B", 2)
c.Set("C", 3)
// 访问 A，A 应该被提升到链表头部
if v, ok := c.Get("A"); !ok || v.(int) != 1 {
t.Fatalf("expected 1, got %v", v)
}
// 新增 D，淘汰最久未访问的 B
c.Set("D", 4)
if _, ok := c.Get("B"); ok {
t.Fatalf("expected B to be evicted")
}
if _, ok := c.Get("A"); !ok {
t.Fatalf("expected A to still exist")
}
if _, ok := c.Get("D"); !ok {
t.Fatalf("expected D to exist")
}
}
你能看到，访问 A 这个动作已经把 A 变成了"最鲜活"的数据，所以后来插入 D 时，被淘汰的是 B 而不是 A。这正是 LRU 的判定逻辑：看你不顺眼，不看你今天用了几次，而是看你最后一次使用是什么时候。
3. 工程里没人用理论 LRU：Redis 与 MySQL 的妥协方案
如果你以为 LRU 就是这个理论版本直接上生产，那还是太年轻了。实际上 Redis 和 MySQL 里的 LRU 都被改了很多版，理解它们的妥协方案，对你设计自己的缓存系统很有帮助。
3.1 Redis 的近似 LRU：采样淘汰
Redis 的内存淘汰策略中有 allkeys-lru 和 volatile-lru。但 Redis 并没有实现上面那种精确 LRU——每个 key 记录一个"最后一次访问时间"，然后每次淘汰时找最旧的。关键在于，Redis 为了高性能，用了近似 LRU。
具体做法是：当需要淘汰数据时，Redis 在键空间里随机采样 N 个 key（默认 N=5，由 maxmemory-samples 配置），然后从这 N 个 key 中选出空闲时间最长的那个淘汰掉。
这个方案最大的好处是省内存——不需要维护双向链表，也不需要维护精确的访问时间队列，每个 key 只需要额外存储一个 lru 时间戳字段。坏处是淘汰不精确，你可能会淘汰掉一个被频繁访问但恰好没被采样到的 key，而留下了真正该淘汰的冷数据。
采样数越大越精确，但 CPU 开销也越高。Redis 默认取 5 是性能和精确度之间的折中。这里有个工程启发：在超大规模数据下，"近似最优"往往比"理论最优"更实际，因为精确维护全局状态的内存和 CPU 成本过高。
3.2 MySQL Buffer Pool 的中分段 LRU
MySQL InnoDB 的 Buffer Pool 也做了改良，它把传统的 LRU 链表分为 young 区和 old 区，比例默认是 63:37。新读取的数据页不是直接放到链表头部，而是先放到 young 区和 old 区的分界点（也就是 old 区的头部）。
这样设计是为了解决什么问题？典型场景是全表扫描。如果执行一条全表扫描 SQL，比如 SELECT * FROM user，MySQL 会读取大量数据页。如果这些页全部被放入 LRU 头部，那么 Buffer Pool 里原本的高频热点会被全部挤出去，造成缓存污染。有了 old 区这个缓冲，全表扫描的数据页只停留在 old 区，如果这一批数据页之后没有被再次访问，它们就会在 old 区逐渐老化淘汰，不会冲击 young 区的热点数据。
只有当一个 old 区的数据页被第二次访问时，它才会被提升到 young 区头部。这就是"两次访问才晋升"的策略，本质上是在 LRU 的时间维度上叠加了一个"最少访问次数"的过滤条件，保证真正热的数据才会进入核心区域。
这个思路在业务系统里同样适用：你可以给 LRU 增加一个"观察期"，新进的数据先让它待在次级区域，只有观察期内被再次触达，才提升为真正的热点，避免突发流量污染缓存。
3.3 Go 生态里的 LRU 实践与选型
在 Go 语言里，除了自己实现，更常见的做法是直接用现成库。我用过比较稳定的是 groupcache 里的 lru.Cache，它和上面你看到的实现思路完全一致，只是做了泛型化和更细致的拆分。如果你的项目对 GC 压力敏感，可以考虑用 freecache，它通过 ring-buffer 的方式存储 value，减少 GC 对象的数量，能显著降低 GC 时间。
我的建议是，业务里优先用库，别重复造轮子。但如果你有特殊的淘汰策略诉求，或者想进一步优化内存布局，那么就基于上面这个实现做二次开发，理解原理后改造比从零开始写要快得多。
4. LFU 图解与 Go 实现：用访问频率做淘汰决策
4.1 LFU 解决的是 LRU 哪个痛点
LRU 有一个很明显的缺陷，用一个例子说明：某个 key 在过去一分钟内被访问了 1000 次，但在最近 1 秒内没有被访问；另一个 key 在最后 1 秒内才被访问过一次。对于 LRU 来说，后者会"插队"到前面，前者反而可能因为长时间未访问被淘汰。但在真实业务中，那个"1 分钟内被访问 1000 次"的 key 大概率才是核心热点，被淘汰后会导致缓存击穿。
LFU 就是冲着这个缺陷来的。它给每个 key 维护一个访问计数器，每次访问时计数器加 1，淘汰时优先淘汰计数器最小的那个。
4.2 哈希表+小顶堆的方案图解
LFU 最常见的实现是 哈希表 + 小顶堆。
- 哈希表：负责 O(1) 地根据 key 找到对应的节点。
- 小顶堆：按照节点的访问次数 frequency 组织，堆顶就是访问次数最少的节点。
访问流程：
code复制1. 访问 key A，哈希表找到节点 A，freq 从 3 变成 4。
2. 在堆中更新节点 A 的位置（自底向上调整）。
3. 如果缓存已满，插入新 key B 时：
先淘汰堆顶节点（freq 最小），再插入 B（freq 初始为 1）。
Go 标准库里的 container/heap 正好帮我们省去了手写堆结构的麻烦，只需要实现 heap.Interface 的 5 个方法：Len、Less、Swap、Push、Pop。
4.3 Go 语言实现 LFU（基于小顶堆）
go复制package lfu
import (
"container/heap"
"sync"
)
type entry struct {
key string
value interface{}
freq int
index int // 在堆中的索引，用于更新操作
}
type priorityQueue []*entry
func (pq priorityQueue) Len() int { return len(pq) }
// Less 小顶堆：freq 小的排前面
func (pq priorityQueue) Less(i, j int) bool {
return pq[i].freq < pq[j].freq
}
func (pq priorityQueue) Swap(i, j int) {
pq[i], pq[j] = pq[j], pq[i]
pq[i].index = i
pq[j].index = j
}
func (pq *priorityQueue) Push(x interface{}) {
n := len(*pq)
item := x.(*entry)
item.index = n
*pq = append(*pq, item)
}
func (pq *priorityQueue) Pop() interface{} {
old := *pq
n := len(old)
item := old[n-1]
old[n-1] = nil
item.index = -1
*pq = old[:n-1]
return item
}
type LFUCache struct {
mu sync.Mutex
capacity int
items map[string]*entry
pq priorityQueue
}
func NewLFUCache(capacity int) *LFUCache {
if capacity <= 0 {
panic("capacity must be positive")
}
return &LFUCache{
capacity: capacity,
items: make(map[string]*entry, capacity),
pq: make(priorityQueue, 0, capacity),
}
}
func (c *LFUCache) Get(key string) (interface{}, bool) {
c.mu.Lock()
defer c.mu.Unlock()
if e, ok := c.items[key]; ok {
// 增加频率，并调整堆
e.freq++
heap.Fix(&c.pq, e.index)
return e.value, true
}
return nil, false
}
func (c *LFUCache) Set(key string, value interface{}) {
c.mu.Lock()
defer c.mu.Unlock()
if e, ok := c.items[key]; ok {
e.value = value
e.freq++
heap.Fix(&c.pq, e.index)
return
}
if len(c.items) >= c.capacity {
// 淘汰堆顶频率最小的
victim := heap.Pop(&c.pq).(*entry)
delete(c.items, victim.key)
}
e := &entry{key: key, value: value, freq: 1}
c.items[key] = e
heap.Push(&c.pq, e)
}
这里要特别注意 container/heap 的一个使用陷阱：当你修改了一个已经在堆中的元素的 freq，必须调用 heap.Fix(c.pq, e.index)，而不能直接改完不管。否则堆的性质被破坏，后面的 Pop 可能无法正确返回最小 freq 的元素。heap.Fix 做的事情是内部把该位置向下/向上调整一遍，保证堆序。在 Get 和 Set 中都要记得这个动作。
另外一个细节是 entry.index 字段。标准库的堆操作不会主动告诉你某个元素被换到了哪个位置，所以如果不自己维护 index，heap.Fix 根本没法调用——你不知道元素当前位置，而 Fix 的入参需要知道位置。这就是为什么结构体里要多存一个 index 字段，并且要在 Swap 方法中同步更新。
4.4 复杂度与代价
LFU 的时间复杂度是 O(log n)，因为每次频率变更都需要调整堆。相比 LRU 的 O(1)，在读写高频场景下，LFU 的堆操作开销会明显一些。空间复杂度两者都是 O(n)。
但我个人建议：如果你的数据规模在几万量级，这个 O(log n) 的差距完全可以忽略；但如果你的缓存有上百万 key，且读多写多，堆的调整代价就会明显放大。此时你需要考虑下一节说的 O(1) 方案。
5. 把 LFU 做到 O(1)：频率桶链表的进阶设计
5.1 为什么需要 O(1) 的 LFU
上一节基于小顶堆的 LFU 实现思路清晰、代码简洁，面试中写到这个水平已经能通过大部分考察。但工程上如果缓存规模很大，O(log n) 的堆调整成本就会逐渐不可忽略。
设想一个场景：你的服务有 100 万个热点 key，每个 key 每秒都被访问几次，那么每秒钟就要做上百万次堆调整，每次调整是 log(1000000)≈20 次比较。这个 CPU 开销在业务高峰期可能是致命的。
LFU 还有一种基于 频率桶链表 的设计，可以让读写都做到 O(1)。
5.2 频率桶的数据结构图解
核心思路是引入"频率桶"的概念：每个频率值对应一个双向链表，桶里面有若干 key。一个 key 的访问频率增加时，它就从当前频率桶移动到下一个更高的频率桶。
结构上由三部分组成：
map[string]*node：key 到节点的映射，O(1) 找到节点。map[int]*bucket：频率值到桶的映射，每个桶是一个双向链表，保存所有当前频率相同的 key。- 一个变量
minFreq：记录当前最小的频率值，淘汰时直接从minFreq桶中取头部节点即可。
访问流程：
code复制1. 节点 A 频率为 3，位于 freq=3 桶中。
2. 访问 A，freq 变为 4。
3. 从 freq=3 桶中摘除 A。
4. 将 A 插入 freq=4 桶的头部。
5. 如果 freq=3 桶空了，删除该桶，并更新 minFreq（如果 A 是唯一的最小频率节点）。
这样，所有操作都变成了哈希表的 O(1) 查找加上双向链表的 O(1) 插入删除，整体复杂度降为 O(1)。
5.3 Go 实现（关键代码）
这个实现会稍微长一些，我给出省略部分次要逻辑的骨架，核心链路的代码都在：
go复制package lfu
import (
"container/list"
"sync"
)
type freqBucket struct {
freq int
list *list.List // 存 *node
}
type node struct {
key string
value interface{}
freq int
element *list.Element // 在所属 bucket.list 中的位置
bucket *freqBucket
}
type LFUCacheO1 struct {
mu sync.Mutex
capacity int
items map[string]*node
buckets map[int]*freqBucket
minFreq int
}
func NewLFUCacheO1(capacity int) *LFUCacheO1 {
return &LFUCacheO1{
capacity: capacity,
items: make(map[string]*node, capacity),
buckets: make(map[int]*freqBucket),
}
}
func (c *LFUCacheO1) incrFreq(n *node) {
oldBucket := n.bucket
oldBucket.list.Remove(n.element)
newFreq := n.freq + 1
n.freq = newFreq
bucket, ok := c.buckets[newFreq]
if !ok {
bucket = &freqBucket{freq: newFreq, list: list.New()}
c.buckets[newFreq] = bucket
}
n.bucket = bucket
n.element = bucket.list.PushFront(n)
// 如果旧桶空了，删除它并更新 minFreq
if oldBucket.list.Len() == 0 {
delete(c.buckets, oldBucket.freq)
if c.minFreq == oldBucket.freq {
c.minFreq = newFreq
}
} else {
// 如果旧桶没空，但 minFreq 对应的桶正好是旧桶且旧桶还有元素
// 说明 minFreq 不需要变化
}
}
这段代码有一个关键判断需要留意：minFreq 的更新。只有当被访问的节点是"最小频率桶中最后一个节点"时，minFreq 才会变成 newFreq。如果旧桶里还有其他节点，minFreq 应该保持不变。这块逻辑非常容易写错，调试时最好打日志验证。
O(1) LFU 的代码量比堆方案多了一倍不止，而且边界条件多。我的建议是：面试聊思路可以，生产环境优先用小顶堆版本先跑通，等通过压测确认了瓶颈确实在堆调整上，再切换成频率桶方案。过早优化是万恶之源。
5.4 频率桶本质：用空间换时间
频率桶方案其实是用一个"冗余"的频率索引（map[int]*bucket）来换取删除和插入时不需要全局搜索最小频率。这在大数据量下是超值的。
6. Redis 的 LFU 实现：一小块数据定生死的艺术
你有没有想过一个问题：Redis 用的是近似 LRU，采样 5 个 key 就淘汰了，那如果换用 LFU，是不是也得把每个 key 的访问次数记录下来？如果每个 key 都存一个 8 字节的计数器，几千万个 key 就要多占用几百 MB 内存，这对 Redis 这种追求极致内存利用率的系统来说是不能接受的。
6.1 概率计数器：Morris Counter
Redis 的 LFU 实现里，频率计数并不是精确的整数，而是一个 4 位半字节（4 bits）的概率计数器，配合一个 24 位的递减时间戳字段，一共只占 28 bits，也就是每个 key 额外占用不到 4 字节。
这 4 bits 能表示多少频率？理论最大值是 15，但 Redis 通过概率递增的方式，让 15 可以代表"非常大"的访问次数。核心思想是：计数器不是每次访问都加 1，而是概率性地加 1，访问越频繁，概率越大，但计数增长越快的地方会趋于饱和。
具体实现参考了 Morris Counter 的思想。计数从 0 开始，第一次访问时计数变为 1。之后计数越高，递增概率越低。当计数接近 15 时，即使后续访问次数再多，计数也只会以极低的概率继续增长。这样 4 bits 就能表达从 1 到百万次级别的访问量，虽然不精确，但在淘汰场景下足够了——我们只需要大致判断"谁更热"就够了。
6.2 衰减机制：时变频率
Redis 的 LFU 还内置了一个衰减逻辑：频率计数会随着时间推移而衰减。默认情况下，计数器的值、上次更新时间戳都会被记录，Redis 会根据 lfu-decay-time 配置，在每次访问时计算这段时间里应该衰减多少。衰减的意义在于：适应访问模式的变化。一个 key 今天很热，明天可能就冷了。如果不衰减，历史峰值会导致它永远占据缓存空间，新晋热数据反而无法进入。
这个思想真的很值得借鉴到业务代码中。我在自己的缓存组件里实现 LFU 时，就给每个 entry 增加了一个 lastAccessTime 字段，定期扫描时按时间比例衰减频率。效果是：算法既能保留高频冷数据的记忆，又不会让"过去的热数据"永远占着位置。
6.3 Redis LFU 的关键配置项
Redis 的 LFU 相关的配置是两个参数：
lfu-log-factor：控制概率计数器的增长速度。数值越大，计数增长越慢。lfu-decay-time：控制衰减速度，单位是分钟。默认值是 1，表示每过 1 分钟，计数衰减一部分。
如果你用 Redis 做缓存，且打算启用 LFU 策略，我建议先压测这两个参数，观察 cache hit rate 的变化。默认参数并不是万金油，对于访问模式高度集中的场景，调大 lfu-log-factor 能让高频热点更快占满计数上限，淘汰效果更精准。
7. LRU 还是 LFU：决策维度和组合方案
讲了这么多，回到核心问题：我做业务系统时到底该用哪个？
7.1 先看你的访问分布
一个简单判断：你的数据访问是否符合"二八定律"，也就是 80% 的请求打在 20% 的热点数据上？
如果是，LRU 和 LFU 都能取得不错的命中率。但两者的差异在下面两个场景会暴露：
| 场景 | LRU 表现 | LFU 表现 |
|---|---|---|
| 突发流量：某个冷 key 短时间内被大量访问 | 表现好，冷 key 会被提到头部，后续快速响应 | 一开始计数低，可能被误杀，需要几次访问后才能判断热度 |
| 访问模式周期性变化：昨天的热点今天冷了 | 表现好，旧热点只要不再被访问，会逐渐自然淘汰 | 需要衰减机制配合，否则旧热点因为有历史计数，长期占坑 |
如果你的业务是"数据热点随时间漂移"的，比如资讯类 App 的实时热门话题，LRU 效果通常更好。如果你的业务是"热点相对固定且持续"，比如数据库热点行缓存、字典数据缓存，LFU 更优。
7.2 行业内的经典组合方案
业界并不是总是二选一，有几个经典思路可以借鉴：
- W-TinyLFU：Caffeine 缓存库的核心算法。它把窗口 LRU 与频率过滤组合起来——新数据先进入窗口 LRU，通过"准入过滤"后再进入主 LRU。主 LRU 内部再根据频率计数进行淘汰。这个思路融合了时间维度和频率维度的优点，对于实时热点和长尾热点都很友好。
- 两级缓存：L1 用 LRU 做热数据缓存，L2 用 LFU 做次热数据缓存。访问时先查 L1，L1 未命中查 L2，L2 命中后 L1 回填。这样可以兼顾短期突发热点和长期访问热点。
7.3 我的个人实践建议
最后给你一套我实际用下来的选型套路：
- 缓存数据量小（几千到几万）、单机部署、并发读多写少：直接用上面第 2 节的 LRU 实现，简单可靠，代码量小，好维护。
- 数据量中等（几十万到几百万）、并发读写均衡：用小顶堆版 LFU，频率调整的 O(log n) 完全扛得住。
- 数据量极大（千万级以上）、热key明显：优先上 Redis，配置
maxmemory-policy allkeys-lfu，并且先用默认参数跑，再根据命中率调lfu-log-factor。 - 如果你想在业务代码里做到"既防突发流量，又防历史热点占坑"：别自己造轮子，直接用 Caffeine，它就是干这个的，而且它在 JVM 上经过多年生产验证，成熟度可靠。Go 生态如果你不想引入重量级依赖，可以用上面说过的 groupcache 改造成 W-TinyLFU 的思路，但要注意这是一条需要投入精力的路。
缓存淘汰算法看着简单，但实际工程中最难的不是实现，而是判断在你的业务下，什么才是"该留下的数据"。LRU 假设最近使用的就是好的，LFU 假设用得多的就是好的，但真实世界比这两个假设都复杂。
我在做那个报表系统的时候，最终方案是把"批量对账扫描查询"的 key 单独放到一个独立的 Redis 实例，业务热数据走正常的 LRU 缓存，两者互不干扰。这个方案比换任何淘汰算法都简单粗暴有效。有时候，与其纠结算法，不如先想想能不能从架构上把不同类型的数据隔离。先优化流量结构，再优化算法参数，这个顺序千万别搞反。