Digital Ocean无状态服务器部署Spring Boot缓存一致性问题咨询

你担心的多实例缓存不一致问题必然会在实际生产部署中出现。
你当前实现的缓存是绑定单实例进程的本地缓存（无论用的是Caffeine、Guava还是Spring Boot默认的简单内存缓存），缓存数据存储在每个JVM进程的独立内存空间中。当实例A处理数据更新请求、触发本地缓存淘汰时，操作仅作用于A自身的进程内存，B、C、D三个实例内存里存储的旧缓存条目完全不受影响，只有等到各自配置的TTL到期才会被自动清理，这段时间内路由到这三个实例的请求都会读到旧数据。这是多实例无状态部署下本地缓存的典型问题，不是配置错误，是本地缓存架构本身的特性决定的。

以下方案按改造成本从低到高、一致性保障强度从弱到强排序，可根据业务实际容忍度选择：

• 维持现有架构+短TTL兜底
  如果业务对短时间的数据不一致容忍度很高（比如公开资讯列表、非实时统计数据、更新频率极低的基础配置），完全不需要做额外架构改造，只需要把现有基于时间的缓存过期TTL调整到业务可接受的最短值即可。就算某台实例残留了旧缓存，最多存活一个TTL周期就会自动淘汰，架构零额外复杂度，运维成本最低。
• 缓存失效事件广播
  如果想保留本地缓存的超低读写延迟，不想引入缓存访问的网络IO开销，可以加一层多实例的缓存失效通知机制：实例A完成数据更新、清理本地对应缓存后，通过发布订阅通道（Redis Pub/Sub、各类MQ都可实现）发送一条携带缓存标识的失效消息，其余所有实例订阅该通道，收到消息后主动清理自己本地对应的缓存条目即可。
  基于Spring技术栈开发不需要手写整套消息收发逻辑，引入Spring Cloud Bus做简单配置就能自动完成事件广播，原有@CacheEvict注解只需要加少量配置就能触发多实例同步清理，改造成本很低。注意要做好消息重试、消费幂等处理，避免消息丢失导致部分实例缓存长期不一致。
• 替换为集中式分布式缓存
  这是生产环境最通用的方案，直接把进程内本地缓存替换为所有实例共享的集中缓存集群（最常用的是Redis），所有实例的缓存读写、淘汰更新都操作同一个缓存集群，从根源上消灭多实例缓存副本不一致的问题。
  Spring Boot适配成本极低，引入spring-boot-starter-data-redis依赖，将缓存管理器切换为RedisCacheManager即可，业务层编写的@Cacheable、@CacheEvict等缓存注解基本不需要改动，迁移成本很小。如果对性能有极致要求，可以搭配Caffeine做一级本地缓存、Redis做二级分布式缓存，本地缓存TTL设为1-3秒的极短值，就算出现不一致也只会影响极短窗口的请求，同时兼顾性能和一致性。

内容的提问来源于stack exchange，提问作者coderperz