本地缓存和分布式缓存有什么区别？什么是多级缓存？

简化版

本地缓存存在应用进程自己的内存里（如 Caffeine、Guava Cache、Ehcache），读取无网络开销、极快，但每台机器一份、容量有限、多实例间不一致。分布式缓存存在独立的缓存服务里（如 Redis、Memcached），所有实例共享一份、容量大、数据一致，但有网络开销、且是外部依赖。多级缓存把两者结合：请求先查本地缓存（L1）→ 未命中查分布式缓存（L2）→ 再未命中查数据库，兼顾速度和一致性、并在 Redis 故障时多一层兜底。

详细版

本地缓存 vs 分布式缓存对比：

维度	本地缓存（Caffeine 等）	分布式缓存（Redis 等）
存储位置	应用进程内存（JVM 堆内/堆外）	独立缓存服务
访问速度	极快（纳秒级，无网络）	快（亚毫秒，有网络 RTT）
容量	受单机内存限制，小	大，可集群扩展
数据共享	每个实例独立一份	所有实例共享一份
一致性	差（多实例各自更新，难同步）	好（单一数据源）
容灾	随应用重启丢失	独立部署，持久化可选

多级缓存的读流程：

请求 → L1 本地缓存（Caffeine）命中？→ 是：返回
                              ↓ 否
       L2 分布式缓存（Redis）命中？→ 是：回填 L1，返回
                              ↓ 否
       数据库 → 回填 L2 和 L1 → 返回

本地缓存适合：读极频繁、变化少、能容忍多实例短暂不一致的数据（如字典、配置、类目树）。
分布式缓存适合：需要多实例共享、一致性要求较高的数据。
多级缓存：热点数据放本地挡下最猛的流量，其余走 Redis。

完整版教学

一、本地缓存：快，但各管各的

本地缓存把数据直接存在应用进程自己的内存里。Java 常用 Caffeine（高性能，W-TinyLFU 算法）、Guava Cache、Ehcache。

最大优点是快：数据就在本进程内存，读取是纳秒级的内存访问，没有任何网络开销，比查 Redis（要走网络、序列化）快一两个数量级。

最大问题是「各存各的」：如果服务部署了 10 个实例，就有 10 份独立的本地缓存。这带来两个麻烦：

一致性差：更新数据时，很难同时通知所有实例更新/失效它们各自的本地缓存。实例 A 更新了，实例 B 的本地缓存还是旧值，读到不一致的数据。
容量受限：受单机内存约束，存不了太多。

所以本地缓存适合很少变、能容忍短暂不一致、访问极频繁的数据——比如系统字典、枚举、类目树、少变的配置。

二、分布式缓存：共享一致，但有网络成本

分布式缓存（Redis、Memcached）是独立于应用的缓存服务，所有应用实例都连到它、共享同一份数据。

优点：

数据共享 + 一致：只有一份数据，所有实例读到的都一样，更新一处即可。
容量大：可以集群横向扩展，存海量数据。
独立容灾：应用重启不丢缓存；Redis 自身可持久化、主从高可用。

代价：

有网络开销：每次读写都要走网络（RTT）+ 序列化/反序列化，比本地缓存慢。
是外部依赖：Redis 挂了会影响所有应用（所以要做高可用 + 兜底）。

三、多级缓存：两者结合，扬长避短

既然本地缓存快但不一致、分布式缓存一致但有网络成本，那就组合起来分层用——这就是多级缓存：

L1（一级）本地缓存：放最热的一小撮数据，挡下最猛的流量，享受纳秒级速度。
L2（二级）分布式缓存 Redis：放更全的数据，保证多实例共享和一致。
L3 数据库：最终数据源。

读流程：先查 L1 本地 → 未命中查 L2 Redis（命中则回填 L1）→ 再未命中查 DB（回填 L2、L1）。越靠上越快、命中越多，大部分请求在 L1/L2 就被满足，DB 压力极小。

额外好处：Redis 故障时的兜底——如果 Redis 挂了，L1 本地缓存还能挡住一部分热点请求，不至于全部瞬间压到 DB，为防雪崩多一道防线。

四、多级缓存的核心难题：本地缓存的一致性

多级缓存最棘手的是如何让各实例的 L1 本地缓存及时失效——数据更新后，Redis 好删，但每台机器的本地缓存怎么同步清？常见方案：

短过期时间：给本地缓存设很短的 TTL（如几秒~几十秒），容忍最多这么久的不一致，简单但有延迟。
消息广播失效：数据变更时，通过消息队列（或 Redis 的 Pub/Sub）广播一个失效通知，所有实例收到后清除自己的本地缓存。较实时，但要引入广播机制、且有短暂延迟。
只缓存「几乎不变」的数据到本地：从源头规避——把本地缓存限定在字典、配置这类极少变的数据上，一致性压力就小。

五、选型建议

只用本地缓存：数据极少变、单机够用、能容忍多实例不一致（小型应用、字典数据）。
只用分布式缓存：需要多实例共享、一致性要求高、数据量大（大多数业务的默认选择）。
多级缓存：超高并发、有明显热点、要极致性能和高可用（大流量核心系统，如商品详情页、首页）。多级缓存复杂度高，别过度设计——没有性能瓶颈时，一层 Redis 就够。

六、常见误区与追问

考点	正确口径
本地缓存	进程内缓存，访问快但容量小、一致性弱
分布式缓存	独立缓存服务，容量和共享性更好
多级缓存	本地缓存挡热点，分布式缓存承载共享数据

request
-> local cache Caffeine
-> Redis cluster
-> database

local TTL 1s, Redis TTL 10min
write DB -> delete Redis -> notify local cache invalidation

多级缓存不是层数越多越好，层数越多，一致性和失效通知越复杂。

误区：本地缓存一定比 Redis 好。 本地缓存快，但每个实例一份副本，容量、共享和一致性都受限。
误区：用了 Redis 就不需要本地缓存。 极热点场景本地缓存能挡住大量 Redis 请求，保护缓存集群。
误区：多级缓存天然一致。 多级副本越多，失效通知、TTL 和更新顺序越容易出问题。
追问：本地缓存适合什么？ 适合配置、字典、短 TTL 热点、读多写少且可容忍短暂不一致的数据。
追问：多级缓存如何失效？ 常用消息广播、版本号、短 TTL、订阅变更事件等方式。
追问：如何防本地缓存撑爆内存？ 设置最大容量、过期策略、淘汰策略和对象大小监控。

七、加强记忆

本地缓存（Caffeine/Guava）存在应用进程内存，极快无网络但每实例一份、容量小、一致性差，适合极少变的字典/配置。分布式缓存（Redis）独立部署，共享一致、容量大但有网络开销、是外部依赖，是多数业务默认。多级缓存组合两者：L1 本地挡最热流量 → L2 Redis 保共享一致 → L3 DB，越靠上越快命中越多，且 Redis 挂了本地兜一层防雪崩。多级缓存的核心难题是本地缓存一致性（用短过期 / 消息广播失效 / 只缓存不变数据来解决）。选型口诀：本地图快但不一致、Redis 一致但有网络、多级组合但别过度设计。

简化版

详细版