随着系统读流量的指数级上升，单纯依赖 Redis 集中式缓存可能会遭遇网络带宽瓶颈以及热点数据的单点性能压制。为了进一步突破性能天花板，在应用进程内引入本地缓存（如 Caffeine 或 Guava Cache），构建“本地缓存 + Redis 分布式缓存”的多级缓存架构，成为许多高吞吐量系统的必选项。
多级缓存架构的运行流程非常明确：客户端请求到达应用后，优先在内存本地缓存中查找数据，命中则直接返回，其耗时几乎可以忽略不计；若本地未命中，则请求跨网络访问 Redis 集群；若 Redis 依然穿透，最后才回源到数据库加载数据，并依次写回 Redis 和本地缓存。这种设计极大降低了网络 I/O 开销，并且将热点数据的读取压力分散到了应用集群的各个节点上。
引入本地缓存带来的最大工程挑战是各节点之间的数据一致性。当数据库记录发生变更时，修改 Redis 缓存相对容易，但如何通知分散在数十个应用节点中的本地缓存失效，则是一个棘手的问题。一种常规做法是通过消息队列（如 Kafka 或 RabbitMQ）广播数据变更事件，各个应用实例订阅该主题，收到消息后主动清除本地缓存。尽管这种异步广播机制能应对大部分场景，但在高并发更新时可能存在消息堆积与延迟，导致短时间内不同节点读取到的数据存在版本差异。
为了缓解这一矛盾，可以结合 Redis 的 Pub/Sub 机制或是较新的客户端缓存特性（Client-side caching）来实现更轻量级的失效通知。应用节点在读取 Redis 数据时，建立跟踪订阅；一旦 Redis 中的原键被修改或淘汰，服务端会向对应的客户端推送失效报文。橙星云技术团队在设计此类架构时，针对不同业务的容忍度采取了分级策略。对于配置信息这类容忍短时间不一致的数据，采用本地短 TTL 自动过期加上异步广播的柔性策略；而对于那些一致性要求较高的数据，则更倾向于直接依赖底层的 Redis 高可用集群，舍弃本地缓存层以规避脏读风险。架构设计本质上是在一致性、可用性和性能之间做权衡，多级缓存正是这一权衡过程的缩影。