多级缓存核心是本地缓存（Caffeine）与分布式缓存（Redis）协同，兼顾性能与最终一致性；需职责清晰、失效可控、降级有路，并强化监控与可观测性。
Java项目实现多级缓存，核心是“本地缓存 + 分布式缓存”协同工作，兼顾性能与一致性。关键不在堆多少层，而在每层的职责清晰、失效可控、降级有路。
本地缓存：用Caffeine做第一道防线
本地缓存响应快（纳秒级）、无网络开销，适合读多写少、变更不频繁的数据，比如配置项、字典表、用户权限白名单。
- 优先选Caffeine（比Guava Cache更现代，支持异步刷新、权重淘汰、统计监控）
- 设置合理size和expireAfterWrite（如10分钟），避免内存泄漏或数据长期 stale
- 禁止直接存大对象（如完整订单列表），可存ID集合，再按需查DB或远程缓存
- 注意：Spring Boot 2.4+ 默认集成Caffeine，@Cacheable可无缝对接，但需自定义CacheManager启用weakKeys/recordStats
分布式缓存：Redis承担共享与穿透防护
本地缓存解决不了节点间一致性问题，Redis作为第二层统一出口，同时承担缓存穿透、击穿、雪崩的防御任务。
- Key设计带业务前缀+版本号（如red">user:v2:10086），便于批量清理和灰度切换
- 值建议用JSON字符串或序列化后的byte[]，避免反序列化兼容问题；高频小字段可用Hash结构节省空间
- 必须设置过期时间（TTL），并加入随机偏移（如基础10分钟 ± 60秒），防雪崩
- 空值缓存（null value + 短TTL）+ 布隆过滤器（拦截99%非法ID请求）双管齐下防穿透
缓存一致性：不是强一致，而是“可接受的最终一致”
多级缓存天然无法强一致，重点是控制不一致窗口、暴露风险、快速修复。
立即学习“Java免费学习笔记（深入）”；
- 写操作采用“先删后写”策略：删除本地缓存 → 删除Redis → 写DB → （可选）异步回填Redis（避免写DB成功但缓存失败导致脏数据）
- 本地缓存不监听Redis事件（如KeyEvent），因网络延迟和消息丢失不可靠；改用“主动失效通知”：服务内广播（Spring Event）或轻量MQ（如Redis Stream）触发各节点清理本地缓存
- 对一致性要求极高的场景（如账户余额），跳过本地缓存，直读Redis+DB，用分布式锁或CAS保障更新安全
监控与降级：让缓存“看得见、控得住、断得稳”
没有监控的缓存等于埋雷。必须暴露命中率、加载耗时、淘汰数、异常频次等核心指标。
- Caffeine开启stats（.recordStats()），通过MeterRegistry上报Micrometer（接入Prometheus/Grafana）
- Redis命令耗时、连接池使用率、超时率（jedis/lettuce均有metrics支持）需实时告警
- 配置运行时开关（如Apollo/Nacos动态属性）：一键关闭本地缓存、降级为只读Redis、甚至全走DB（熔断）
- 缓存初始化阶段加预热逻辑（启动时加载热点key），避免冷启动流量打垮DB
基本上就这些。多级缓存不是堆技术，而是权衡的艺术——本地缓存保速度，Redis保共享，一致性靠流程设计，稳定性靠可观测与降级能力。不复杂但容易忽略细节。
