缓存是什么、什么时候用

缓存是提性能的利器，通俗说是"把常用数据放桌面，取快"。 这篇讲清是什么和什么时候用。

后端开发里有一句老话：能加缓存就别升级数据库。这句话虽然夸张，但点出了缓存的本质——用更快的存储介质来兜住热点数据，让系统用更低的成本扛住更高的并发。这篇我们从原理、价值、常用方案、使用场景、注意点、坑点和落地路径七个方面把缓存讲透，帮非技术背景的产品和业务同学也能理解。

缓存是什么

把常用数据临时存在访问快的地方（内存）：

查数据 → 先查缓存（快）→ 有直接返回
                      没有再查数据库（慢）→ 存入缓存

类比：常用文件放桌面（缓存），不常用的在档案柜（数据库）。

这个类比非常贴切。硬盘和 SSD 就像档案柜，容量大但每次取东西都要走过去、翻找、取回，慢；内存（RAM）就像办公桌面，容量小但伸手就到，快。数据库的数据默认存在硬盘上，每次查询都要做磁盘 I/O，遇到复杂查询或大数据量时延迟会显著上升。缓存的核心思路就是把高频访问的数据从硬盘搬到内存里，应用程序直接从内存读，延迟从几十毫秒降到亚毫秒级。当缓存里没有要查的数据（俗称"未命中"），才回退到数据库查，并把结果写回缓存，下次再查就直接命中。

为什么用缓存

1. 提速

内存访问比数据库快得多，这是缓存的根本价值。一次数据库查询如果走磁盘 I/O，可能要几毫秒到几十毫秒；同样一次内存读取通常在微秒级别，差距能达到两到三个数量级。对于电商详情页、API 接口、后台列表这类高频场景，提速带来的体验改善非常直接——用户感知的"卡顿"往往就发生在那几十毫秒上。

2. 减轻数据库

常用数据缓存命中后，数据库就不用再处理这些查询。数据库是大多数系统里最贵的资源之一，CPU、内存、连接数都有上限，一旦被打满整个系统就拖垮。把热点数据放进缓存，相当于给数据库装了一个"减压阀"，让它专注于真正复杂、不能缓存的查询。

3. 提并发

缓存扛得住高并发，这是另一个被低估的优势。Redis 单实例常见可支撑每秒数万到数十万次读写，且响应稳定。而关系型数据库的并发能力受连接池、锁、事务复杂度等多重约束，一旦并发上来就容易抖动。在秒杀、抢购、热点内容这种瞬时高并发场景，缓存几乎是唯一现实的扛量手段。

常用缓存

• Redis：主流内存缓存，支持丰富数据结构（字符串、哈希、列表、集合、有序集合），可持久化，分布式支持好，是当下最主流的选择。
• Memcached：简单缓存，只有键值对、纯内存，适合简单的字符串缓存场景。
• 本地缓存：应用进程内的缓存（如 Caffeine、Guava Cache），延迟最低但不能跨实例共享，适合单机或少量数据的极热缓存。

实际项目里常常是"本地缓存 + Redis"的组合：本地缓存兜住最热的少量数据，Redis 兜住分布式共享的中热度数据，形成两级缓存。

什么时候用缓存

适合

商品信息、系统配置、字典数据、热门文章、热搜榜单都属于"读多写少"或"变化不频繁"的典型场景。比如一个电商详情页的商品基础信息，一天可能被读几万次，但商品参数一年也改不了几次，缓存命中率几乎 100%，回报极高。

不适合

• 频繁变化（缓存频繁失效，缓存价值低，反而增加维护成本）。
• 要强一致（缓存和数据库之间存在窗口期，强一致场景要么用复杂的一致性协议，要么干脆不用缓存）。
• 冷数据（访问频率极低，缓存占用空间又几乎不命中，纯粹浪费）。

缓存的注意点

1. 缓存更新

数据变了缓存要更新，否则读到旧数据。常见的策略有：写数据库时同步更新缓存、写数据库时删除缓存让下次读时回源、给缓存设置较短的过期时间让数据自然失效。每种策略都有取舍，没有银弹，要根据业务对实时性的要求来选。

2. 一致性

缓存和数据库之间的一致性是分布式系统的经典难题。CAP 理论告诉我们一致性和可用性不可兼得，缓存场景下通常做的是"最终一致"——允许短暂不一致，但通过过期时间、版本号、消息队列等手段保证最终收敛。如果业务要求强一致（比如金融余额），那就要慎重考虑是否用缓存，或者用复杂的事务机制来保证。

3. 缓存失效

缓存失效有三种典型异常情况，俗称"三大坑"。雪崩是大量缓存同时过期，请求瞬间打到数据库上把它压垮；穿透是大量查询缓存里本来就没有、数据库里也没有的数据，每次都回源；击穿是某个热点 key 突然过期，瞬间海量请求同时回源。每种都有对应的应对策略，比如过期时间加随机偏移防雪崩、空值缓存或布隆过滤器防穿透、互斥锁防击穿。

4. 容量管理

缓存容量有限，必须有淘汰策略。常见的有 LRU（最近最少使用）、LFU（最不常用）、FIFO（先进先出）、TTL（按过期时间）。Redis 默认提供 noeviction、allkeys-lru、volatile-lru 等多种策略，要根据数据访问模式选择。容量管理做不好，要么缓存命中率低（数据频繁被淘汰），要么内存被吃光引发 OOM。

别踩的坑

• 缓存不更新：数据变了缓存还存着旧值，用户看到错误信息。
• 忽视一致性：多个副本或多个服务看到的缓存数据不一致，引发诡异 bug。
• 缓存失效没处理：雪崩压垮数据库，原本为了提性能反而引发事故。
• 不该缓存的缓存：强一致场景或冷数据场景硬上缓存，得不偿失。

成本参考

开源 Redis 自建成本主要在服务器和运维人力；云托管缓存（如阿里云 Tair、AWS ElastiCache）按规格付费，省运维但成本随规格线性增长。

怎么用

1. 识别读多写少/慢查询，找到真正能从缓存获益的环节。
2. 加缓存，从最热的几个接口或数据入手。
3. 处理更新和一致性，根据业务实时性需求选策略。
4. 处理失效（雪崩/穿透），提前做好防御。
5. 监控缓存效果，关注命中率、内存使用、慢查询等指标。

广州市汉诺雷斯（HNREIS）帮企业做性能优化（含缓存），提升系统速度。把你的性能需求告诉我们，我们给出方案。