缓存对API性能的重要性
一个典型的API请求中，数据库查询占用了80%以上的响应时间。引入缓存后，将热点数据存储在内存中，API响应时间可以从200ms降到5ms，数据库负载直接降低90%-95%。对于高并发API场景，缓存不是可选项，是必需品。
API缓存的三级架构
推荐构建三级缓存体系：L1 - 本地缓存（如Caffeine/Guava Cache，微秒级响应，适合热点数据的极致加速）、L2 - Redis分布式缓存（毫秒级响应，所有服务实例共享，适合大部分API数据缓存）、L3 - CDN边缘缓存（适合静态或准静态API响应，就近返回给用户）。
第一级：本地缓存
本地缓存（进程内缓存）拥有最快的访问速度，但容量受限于JVM堆内存。适用场景：配置数据、字典数据、极少变化的热点数据。推荐使用Caffeine（Java）或cachetools（Python）。注意：本地缓存的数据在多实例部署时可能不一致，需要设置合理的过期时间来降低不一致风险。
第二级：Redis分布式缓存
Redis是API缓存的主力军。支持丰富的数据结构（String/Hash/List/Set/SortedSet），非常适合缓存API响应、用户Token、Session、限流计数器等。关键考量：内存规划（maxmemory设置 + 淘汰策略maxmemory-policy）、高可用（Sentinel/Cluster模式）、序列化（JSON/Protobuf/MsgPack的选择）。
第三级：CDN边缘缓存
对于全国甚至全球用户访问的API，CDN边缘缓存能大幅降低网络延迟。适用条件：API响应在不同用户间相同（如公共配置API、新闻列表API），响应缓存时间可以接受（TTL >= 1分钟）。通过Cache-Control头控制CDN缓存行为。
缓存策略选择
Cache-Aside（旁路缓存）——应用先查缓存，未命中则查数据库并回填缓存。最常用，灵活性最高。Read-Through——应用只与缓存交互，缓存负责查数据库。简化应用代码。Write-Behind——应用只写缓存，缓存异步批量写入数据库。写入性能最高但有一致性风险。
缓存一致性难题与解决方案
缓存一致性是分布式系统中最难的问题之一。常用方案：Cache-Aside + TTL（最简单，允许短时间不一致）、先更新数据库再删除缓存（常用，但极端情况下可能不一致）、延迟双删（先删缓存→更新DB→延迟后再删一次）、Canal + Binlog（监听MySQL Binlog自动更新缓存，最终一致性方案）。
缓存穿透/击穿/雪崩防护
缓存穿透（查询不存在的数据）→ 布隆过滤器 + 空值缓存；缓存击穿（热点Key过期瞬间大量请求打到DB）→ 互斥锁 + 逻辑过期；缓存雪崩（大量Key同时过期）→ 过期时间加随机值 + 多级缓存 + 限流降级。