面试官连环追问LRU算法怎么实现Redis和MySQL里用到了哪些置换策略在技术面试中缓存淘汰策略是一个高频考点。当面试官要求你手写LRU实现时他们真正考察的是你对计算机科学基础知识的掌握程度以及能否将理论应用到实际系统中的能力。今天我们就从链表与哈希表的基础实现出发逐步深入到Redis和MySQL这些主流系统中缓存管理的工业级解决方案。1. 从零实现LRU算法LRULeast Recently Used的核心思想是最近最少使用。想象你有一个只能放5本书的书架当你想放入第6本时就需要把最久未读的那本拿走。在计算机中这个书架就是内存而书本就是缓存的数据项。1.1 基础数据结构选择实现LRU需要同时满足两个操作快速查找O(1)时间复杂度维护访问顺序O(1)时间复杂度这让我们自然想到哈希表双向链表的组合class ListNode: def __init__(self, keyNone, valueNone): self.key key self.value value self.prev None self.next None class LRUCache: def __init__(self, capacity: int): self.capacity capacity self.hashmap {} # 初始化头尾哨兵节点 self.head ListNode() self.tail ListNode() self.head.next self.tail self.tail.prev self.head注意双向链表的头尾使用哨兵节点可以避免许多边界条件检查这是工程实践中常用的技巧。1.2 关键操作实现插入新元素时的处理流程检查key是否已存在哈希表中如果存在则更新值并移动到链表头部如果不存在创建新节点并添加到链表头部存入哈希表检查容量是否超出若超出则移除链表尾部节点def put(self, key: int, value: int) - None: if key in self.hashmap: node self.hashmap[key] node.value value self._move_to_head(node) else: if len(self.hashmap) self.capacity: self._remove_tail() node ListNode(key, value) self.hashmap[key] node self._add_to_head(node)访问元素时的处理def get(self, key: int) - int: if key not in self.hashmap: return -1 node self.hashmap[key] self._move_to_head(node) return node.value1.3 时间复杂度分析操作时间复杂度实现方式查询O(1)哈希表直接访问插入O(1)哈希表插入链表调整删除O(1)哈希表删除链表调整这种实现方式在LeetCode第146题中是一个经典解法也是面试中最常被考察的实现方案。2. 页面置换算法家族LRU只是页面置换算法中的一员理解它的亲戚们有助于我们在系统设计中做出更合适的选择。2.1 常见算法对比算法名称描述优点缺点实现复杂度OPT淘汰未来最长时间不被访问的页面理论最优缺页率无法实际实现N/AFIFO淘汰最早进入的页面实现简单Belady异常性能差低LRU淘汰最久未使用的页面性能接近OPT硬件实现成本高高CLOCK近似LRU的环形检查算法平衡性能与实现成本不如LRU精确中2.2 CLOCK算法的工程实践CLOCK算法是LRU的近似实现被广泛应用于操作系统中。它的核心思想是所有页面组成一个环形链表每个页面有一个访问位reference bit需要置换时指针顺时针扫描遇到访问位1的页面置为0并跳过遇到访问位0的页面选择置换// 简化的CLOCK算法伪代码 Page* clock_algorithm() { while(true) { Page* page clock_hand-next; if(page-referenced 1) { page-referenced 0; } else { return page; // 找到置换目标 } clock_hand page; } }改进型CLOCK算法还考虑了页面是否被修改过dirty bit优先置换既未被访问又未被修改的页面减少磁盘I/O。3. Redis中的缓存淘汰策略Redis作为一个内存数据库提供了多种maxmemory-policy配置选项这些策略直接影响Redis的性能表现。3.1 Redis支持的策略noeviction不淘汰写入操作返回错误allkeys-lru所有key中淘汰最近最少使用的volatile-lru仅淘汰设置了过期时间的key中的LRUallkeys-random随机淘汰所有keyvolatile-random随机淘汰过期keyvolatile-ttl优先淘汰剩余存活时间短的key提示在Redis 4.0后增加了LFULeast Frequently Used策略通过统计访问频率而非最近访问时间来做出淘汰决策。3.2 Redis近似LRU实现Redis并未使用标准的LRU实现而是采用了一种采样近似的方法维护一个全局LRU时钟24位精度到秒每个对象记录最后一次访问时的时钟值需要淘汰时随机选取5个可配置key从中选择最久未使用的key淘汰这种实现虽然不够精确但大幅减少了内存开销和CPU消耗。在redis.conf中可以通过以下参数调整maxmemory-policy allkeys-lru maxmemory-samples 54. MySQL的Buffer Pool管理MySQL的InnoDB存储引擎使用缓冲池(Buffer Pool)来缓存表数据和索引其管理策略是数据库性能的关键。4.1 Buffer Pool基本结构Buffer Pool被组织为一个页链表包含几个重要子列表free list空闲页列表LRU list包含所有被使用的页new sublist5/8最近被访问的年轻页old sublist3/8年老页-- 查看Buffer Pool状态 SHOW ENGINE INNODB STATUS\G4.2 InnoDB的LRU优化MySQL对标准LRU做了重要改进冷热分离新读入的页先放入old sublist头部停留时间窗口只有页在old sublist中存活超过1秒后再次被访问才会移动到new sublist批量读取优化预读的页默认不会立即提升到new区这种设计有效防止了全表扫描等操作污染Buffer Pool。相关参数包括innodb_buffer_pool_size 8G innodb_old_blocks_pct 37 # old区占比(默认37%) innodb_old_blocks_time 1000 # 停留阈值(ms)4.3 页面刷新策略InnoDB通过后台线程定期刷新脏页主要策略有LRU Flush从LRU列表尾部淘汰干净页必要时刷脏Flush List按修改时间顺序刷新脏页Adaptive Flushing根据工作负载动态调整刷新速率5. 现代系统中的应用变体在实际系统中纯粹的LRU往往需要各种优化以适应特定场景。5.1 Linux页面缓存Linux内核使用改进的CLOCK算法管理页面缓存维护active_list和inactive_list两个链表新页加入inactive_list头部再次访问时提升到active_list页面回收主要从inactive_list尾部进行可以通过/proc/meminfo观察相关指标$ cat /proc/meminfo | grep Active Active: 892364 kB Inactive: 345216 kB5.2 硬件TLB管理现代CPU的TLBTranslation Lookaside Buffer通常采用全相联或组相联结构伪LRU替换策略由于硬件实现限制支持大页HugePage等特殊优化在性能敏感场景中理解TLB行为对优化内存访问至关重要。6. 面试实战建议当面试官追问LRU及相关问题时可以按照以下逻辑展开基础实现先给出哈希表双向链表的经典方案算法对比分析LRU与FIFO/CLOCK等的优劣实际问题讨论在真实系统中的变体和优化场景选择根据读写比例、访问模式等推荐策略例如当被问到如何设计一个图片缓存系统时可以这样回答我会考虑使用改进的LRU策略因为图片访问具有局部性LRU能很好利用这一点可以引入二级哈希来支持按目录或用户隔离对大图片和小图片采用不同策略结合预取机制提前加载可能需要的图片