电商多级缓存需分层协同：Caffeine作本地快缓存，Redis为共享稳中枢，DB为最终权威源；读走Caffeine→Redis→DB→回填，写坚持先删后写；辅以监控、降级与预热保障可用性。
电商系统多级缓存不是堆叠几层缓存就完事，关键在于让本地缓存快、分布式缓存稳、数据流转准、故障时有退路。核心是用 Caffeine 做第一道响应屏障，Redis 做共享与兜底中枢，数据库作为最终权威源，三者职责分明、协同有序。
本地缓存：用 Caffeine 拦住高频小数据
Caffeine 是 Java 项目中本地缓存的首选，它比 Guava Cache 更轻量、淘汰策略更智能、支持异步加载和统计监控。
- 设置合理容量和过期策略：比如
.maximumSize(1000)防止内存溢出，.expireAfterWrite(5, TimeUnit.MINUTES)控制数据新鲜度；对配置类、字典项等低频变更数据，可设为 10–30 分钟 - 不存大对象：避免直接缓存整页商品列表，改存 ID 列表（如
List<Long>），再按需查 Redis 或 DB，降低 GC 压力 - 启用统计功能：
.recordStats()开启后，可通过 Micrometer 上报命中率、加载耗时等指标，接入 Prometheus 实时观测 - Spring Boot 中快速集成：2.4+ 版本自动支持 Caffeine，只需配置
spring.cache.type=caffeine并定义CacheManager即可对接@Cacheable
分布式缓存：用 Redis 承载共享与穿透防护
Redis 是多级缓存的第二道主干，解决本地缓存无法覆盖的一致性与容量问题，同时承担缓存穿透、击穿、雪崩的防御任务。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- Key 设计带业务前缀与版本号：例如
product:v2:10086，便于灰度发布时批量清理旧缓存，也避免不同环境 key 冲突 - 值序列化建议用 JSON 字符串（如 FastJSON）：兼容性好、可读性强；高频小字段（如库存、价格）可用 Redis Hash 结构节省空间
- 必须设 TTL 并加随机偏移：基础过期时间（如 10 分钟）叠加 ±60 秒随机值，防止大量 key 同时失效引发雪崩
- 双保险防穿透：对非法 ID 请求，先用布隆过滤器拦截 99% 流量；对真实但无数据的查询，缓存空值（
null+ 短 TTL，如 3 秒） - 热点 Key 重建加锁：用
SETNX或 RedLock 保证只有一个线程回源加载，避免 DB 被打爆
缓存协同：读写路径清晰、一致性可控
多级缓存天然无法强一致，目标是“可接受的最终一致”——控制不一致窗口、暴露风险、快速修复。
立即学习“Java免费学习笔记（深入）”；
- 读流程固定为：Caffeine → Redis → DB → 回填 Redis → 回填 Caffeine（异步或同步依场景定）
- 写操作坚持“先删后写”：更新 DB 成功后，立即删除 Redis 对应 key；再异步触发 Redis 回填（避免 DB 成功但缓存失败导致脏数据）；本地缓存采用短 TTL（如 30 秒）自然失效，不主动删除
- 跨实例本地缓存同步靠轻量通知：不依赖 Redis KeyEvent（不可靠），改用 Spring Event 广播或 Redis Stream 发送失效消息，各节点收到后清理对应本地 key
- 高一致性场景绕过本地缓存：如用户余额、订单状态等，直接读 Redis + DB，配合 CAS 或分布式锁保障原子更新
可观测与降级：让缓存不黑盒、出问题能切
没有监控的缓存等于定时炸弹，没有开关的缓存等于没留逃生通道。
- 暴露核心指标：Caffeine 的命中率、淘汰数；Redis 的命令延迟、连接池使用率、超时频次；全部接入 Grafana + Prometheus 实时告警
- 运行时动态开关：通过 Nacos 或 Apollo 配置全局开关，支持一键关闭本地缓存、切换为只读 Redis、甚至全量降级走 DB（熔断）
- 缓存预热机制：在服务启动或活动开始前，主动加载首页推荐、热门商品等核心数据到 Redis 和本地缓存，避免冷启动抖动
- 日志埋点关键路径：记录每次缓存访问的层级、是否命中、耗时、异常原因，便于问题定位和性能分析
