- 正确答案：设计缓存需综合考虑缓存策略（如LRU、LFU、FIFO）、缓存一致性、并发安全、过期机制、容量控制、数据加载方式（Cache-Aside、Read/Write-Through、Write-Behind）以及底层存储结构（哈希表+双向链表实现LRU，或跳表+计数器实现LFU）。典型高性能本地缓存如Guava Cache或Caffeine，分布式缓存如Redis则需额外处理集群、分片、高可用与持久化。 - 解答思路：首先明确缓存设计目标——降低后端压力、提升响应速度、保证数据近似一致性；然后拆解核心维度：（1）缓存位置：本地（JVM内，如ConcurrentHashMap+LinkedBlockingDeque）、进程外（Redis/Memcached）、多级（L1本地+L2分布式）；（2）缓存粒度：按业务实体（User:1001）、接口结果（/api/user/1001）、还是计算结果（sum(order_items)）？粒度越细，命中率越高，但管理成本上升；（3）缓存生命周期：主动失效（显式delete）、被动过期（TTL）、惰性淘汰（get时检查是否过期）、定时扫描清理；（4）并发控制：读多写少场景下，用读写锁或无锁结构（如CAS+volatile字段）避免缓存击穿；热点key需加逻辑锁（如Redis SETNX）防雪崩；（5）一致性保障：采用Cache-Aside模式（应用层双写：先删缓存再更新DB，或先更新DB再删缓存），配合延迟双删+binlog监听补偿；强一致场景慎用缓存，或引入版本号/时间戳校验；（6）驱逐策略选型：LRU适合访问局部性明显场景（如用户会话热数据），但易受偶发扫描干扰；LFU更稳定但需维护频次计数，存在冷启动和计数老化问题；TinyLFU（Caffeine采用）用Count-Min Sketch估算频率+滑动窗口淘汰，空间效率高且抗扫描干扰；（7）异常降级：缓存不可用时自动回源DB，并触发告警与熔断（如Hystrix fallback）。 - 深度知识讲解： ▶ 底层数据结构实现（以LRU为例）：标准LRU需O(1) get + O(1) put + O(1) 最近最少访问节点淘汰 → 必须结合哈希表（快速定位）与双向链表（维护访问序）。Java中可基于LinkedHashMap（accessOrder=true）重写removeEldestEntry，但其非线程安全；高并发下需自研：用ConcurrentHashMap存储key→Node映射，Node含key/value/pre/next引用，头尾哨兵节点构成循环双向链表；每次get将对应Node移至链表尾（最新访问），put时若超容则移除头节点（最久未用），所有操作通过CAS+volatile保证可见性与原子性。伪代码如下： ``` class LRUCache { final int capacity; final ConcurrentHashMap> map; final Node head, tail; // 哨兵节点 public LRUCache(int capacity) { this.capacity = capacity; this.map = new ConcurrentHashMap<>(); this.head = new Node<>(null, null); this.tail = new Node<>(null, null); head.next = tail; tail.pre = head; } V get(K key) { Node n = map.get(key); if (n == null) return null; moveToTail(n); // CAS更新pre/next指针 return n.value; } void put(K key, V value) { Node n = map.get(key); if (n != null) { n.value = value; moveToTail(n); } else { n = new Node<>(key, value); map.put(key, n); appendToTail(n); if (map.size() > capacity) { Node toRemove = head.next; removeNode(toRemove); map.remove(toRemove.key); } } } void moveToTail(Node n) { /* CAS断开原链接，插入tail前 */ } void appendToTail(Node n) { /* 插入tail前，CAS更新tail.pre等 */ } void removeNode(Node n) { /* CAS断开n.pre/n.next链接 */ } } ``` ▶ LFU进阶实现难点：单纯用HashMap + PriorityQueue无法O(1)淘汰（堆调整O(log n)）； Caffeine采用TinyLFU：用Count-Min Sketch（多个hash函数+二维数组）近似统计访问频次，误差有界；再结合SLRU（Segmented LRU）分段管理：probation（试探区）、protected（保护区）、candidate（候选区），仅在candidate区用TinyLFU筛选待淘汰项，大幅降低内存与计算开销；同时引入Window TinyLFU（滑动窗口）解决突发流量导致旧高频key被误删的问题。 ▶ 缓存穿透/击穿/雪崩本质与根因： - 穿透：查不存在的key（如id=-1），大量请求直击DB → 解决：布隆过滤器（BloomFilter）前置拦截；空值缓存（cache null with short TTL）；参数校验； - 击穿：热点key过期瞬间，大量并发请求同时重建缓存 → 解决：逻辑锁（setnx key_lock 1 ex 30）；永不过期+后台异步刷新（refresh ahead）； - 雪崩：大量key同一时刻过期 → 解决：TTL随机化（baseTTL + random(0,10%*base)）；分级过期（按热度设置不同TTL）；多级缓存（本地缓存扛住第一波）。 ▶ 分布式缓存一致性协议： Redis Cluster采用Gossip协议同步节点状态，但不保证跨slot事务一致性；缓存与DB最终一致依赖应用层设计；强一致场景可引入Cache Stampede防护（如使用Redis的RedLock或Etcd分布式锁协调重建）；更前沿方案是Change Data Capture（CDC）：监听MySQL binlog，通过Canal/Kafka将变更事件推送到缓存服务，实现异步精准失效。 ▶ 容量预估与监控指标：缓存大小 ≠ 数据库大小 × 热点比例，需基于QPS、平均对象大小、存活时间、GC压力建模；关键监控项：hit rate（>95%健康）、load time（加载耗时）、eviction count（淘汰频次）、miss storm（突增miss）、stale reads（过期读取占比）。 - 扩展知识： • 缓存语义分类：Strict Consistency（理论模型，不可达）、Sequential Consistency（多核CPU内存模型）、Causal Consistency（分布式系统常用）、Eventual Consistency（最终一致，缓存典型）； • 新硬件适配：Intel Optane Persistent Memory可构建“内存级持久化缓存”，兼顾DRAM速度与NVM容量； • Serverless场景：Lambda冷启动导致本地缓存失效，需转向外部托管缓存（如ElastiCache）或采用嵌入式轻量缓存（如Caffeine with async refresh）； • AI驱动缓存：用LSTM预测访问模式，动态调整TTL与预热策略（如Facebook的Prodigal系统）。以上设计需根据实际场景权衡：高并发低一致性要求（电商商品页）倾向多级缓存+LRU+Cache-Aside；金融交易类（账户余额）则必须牺牲部分性能，采用Write-Through+强校验+短TTL+实时binlog同步。

滴滴日常实习后端java一面

全站热榜

创作者周榜