分布式缓存Java如何实现，有哪些框架？

对于Java开发者来说，分布式缓存不是可选项而是高并发系统的刚需，实际项目中超过九成团队会选择Redis作为核心方案，搭配Spring Cache注解即可快速落地，但需要提前规划好一致性、穿透和雪崩的应对策略。

平时写代码,从单机到集群，数据量一上来数据库就扛不住，缓存必然上场，本地缓存不够用，自然过渡到分布式缓存，分布式缓存把数据分散到多台机器上，既能扩展容量又能分摊压力，是高性能服务的标配。

加载中

SpringCache整合Redis数据库，实现Java分布式高性能缓存架构【Redis开发实战】

李兴华-yyds

181214-

原视频地址

在Java生态里,分布式缓存的选择很多，但最主流的无疑是Redis，Memcached曾经流行，现在用的人少了，Ehcache虽然支持分布式，但更多还是作为本地缓存来用，这篇文章主要围绕Redis，也会聊聊其他方案做对比。

分布式缓存和本地缓存区别，Java项目怎么选？

很多新手会纠结,项目到底用本地缓存还是分布式缓存？关键看两点：数据量多大，是否需要多实例共享。

本地缓存的局限

本地缓存,像Caffeine、Guava Cache、Ehcache，它们把数据存在JVM堆内存里，访问速度极快，因为没有网络开销，但缺点也很明显：第一，容量受限于单机内存，撑死几十GB；第二，集群环境下每个节点缓存各自独立，数据不一致；第三，热点数据重复存储，浪费内存，本地缓存适合单机应用，或者缓存数据量小、节点数少的场景。

分布式缓存的优势

分布式缓存,比如Redis集群，数据在多个节点间分片，总容量可以轻松扩展到TB级别，而且所有Web节点共享一份缓存，数据一致性有保障，Redis的主从复制和哨兵机制保证了高可用，即使部分节点故障也不影响整体服务，在Java大型项目中，分布式缓存是标配，几乎所有互联网公司都在用。

选型场景怎么判断？

• 如果项目就是单机部署,缓存数据量小，用Caffeine就足够了，简单高效。
• 如果项目是集群环境,哪怕只有两台服务器，也建议上分布式缓存，避免缓存不一致。
• 如果数据量超过单机内存,或者需要缓存持久化，那就必须分布式。
• 如果是微服务架构,多个服务共享数据，分布式缓存也是唯一选择。

初步判断是：能用分布式就别用本地，除非你只有一台机器。

Java分布式缓存方案对比：Redis、Memcached、Ehcache

选方案时,技术选型是永恒的话题，我们对比一下主流的几个。

Redis：功能全面，但需单独部署

Redis是当下最流行的,支持丰富的数据结构（String、Hash、List、Set、Zset、Bitmap等），还支持持久化、过期策略、发布订阅、Lua脚本等，Java客户端有Jedis、Lettuce，以及Spring Data Redis，Redis官方推荐Lettuce，因为它基于Netty，支持异步和响应式，如果你用Spring Boot，直接引入spring-boot-starter-data-redis，默认就是Lettuce，Redis的持久化支持RDB和AOF两种模式，RDB适合数据备份，AOF数据更完整但性能略低，可以根据业务场景选择。

Memcached：简单高效，但功能有限

Memcached是纯内存缓存,不支持持久化，数据结构只有简单的Key-Value，它的优势是内存分配非常高效，内存碎片少，并发性能极高，但功能太单一，现在很多场景下都被Redis替代了，除非你的业务非常单纯，只需要KV缓存，并且对内存利用率要求极高，否则不建议选它，Memcached的Java客户端像是Spymemcached，但更新频率不如Redis客户端。

Ehcache：本地缓存，支持分布式

Ehcache是一个老牌Java缓存框架,它可以嵌入在JVM中，也支持通过RMI或JMS等方式实现分布式缓存，但它的分布式方式比较“重”，需要配置对等节点，不适合大规模集群，现在更多被用作本地缓存，配合Redis做两级缓存（Ehcache+L1，Redis+L2）来提升性能，Ehcache在Spring Boot中也有自动配置，但使用场景逐渐缩小。

对比表格

从功能、社区、生态来看，Redis是Java分布式缓存的首选，没有之一，Memcached逐渐边缘化，Ehcache更适合作为本地缓存补充。

分布式缓存一致性怎么保证？Java实战经验

缓存一致性问题,是分布式系统中绕不开的坑，就是数据库和缓存之间的数据不一致，导致用户读到旧数据。

缓存更新策略

常见的更新策略有几种：

• Cache Aside：读数据时先读缓存，没有则读数据库并回写缓存；写数据时先更新数据库，再删除缓存，这是最常用的模式，行业共识认为这是最稳妥的方式。
• Read/Write Through：缓存层代理数据库，读写都通过缓存，但实现复杂，一般不用。
• Write Behind：批量异步写入数据库，性能高但可能丢数据。

最终一致性方案

在大多数场景下,我们接受最终一致性，更新数据库后删除缓存，下次读时再从数据库加载，短暂的不一致可以接受，这种方案简单有效，但可能遇到删除缓存失败的情况，导致脏数据，解决办法是加上重试机制，或者用消息队列异步删除，还可以采用延时双删策略：先删除缓存，再更新数据库，然后延迟一段时间再次删除缓存，但需要根据业务评估延迟时间。

强一致性场景处理

如果业务要求强一致性,比如库存扣减、金融交易，缓存就不能随意用了，通常的做法是：

不使用缓存，直接读写数据库，或者通过分布式锁控制并发访问，保证同一时间只有一个线程更新缓存和数据库，但这样会牺牲性能，需要权衡，业内专家指出，实际项目中超过80%的场景下，最终一致性就足够了，不必过度追求强一致。

分布式缓存常见问题及应对

生产环境总会遇到一些经典问题,我们提前准备好应对方案。

缓存穿透、击穿、雪崩

• 缓存穿透：查询一个不存在的数据，每次都会穿透缓存请求数据库，解决方案：缓存空对象（设置较短的过期时间），或者使用布隆过滤器预判是否存在。
• 缓存击穿：热点key过期，大量并发请求同时打到数据库，解决方案：互斥锁（setnx），或者热点key设置永不过期（后台异步更新）。
• 缓存雪崩：大量key同时过期，或者Redis宕机，导致请求全部打到数据库，解决方案：过期时间加随机值，Redis高可用集群，限流降级。

热点key处理

业务中可能出现某个key被高频访问,比如双十一的秒杀商品，这个key所在的Redis节点压力会很大，解决方案：将热点key分散到多个副本，比如在key后面加一个随机后缀，让请求分散到不同节点，或者使用本地缓存兜底，但要注意一致性问题，在实际编码中，可以通过监控统计每个key的访问频率，提前发现热点。

监控与运维

Redis集群的监控必不可少,重点关注内存使用率、命中率、慢查询、主从延迟等，常用的工具有Redis自带的INFO命令、Redis-cli的–stat，以及Prometheus+Grafana监控方案，在Java端，可以通过Actuator暴露Redis健康指标，方便集成到监控系统，日志中记录缓存操作的耗时和异常，有助于快速定位问题。

Java分布式缓存实践：从入门到生产

理论讲完,我们看看实际怎么用。

Spring Boot集成Redis

如果你用Spring Boot，集成Redis非常简单，在pom.xml中添加依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

然后在application.yml中配置Redis连接信息，默认是Lettuce客户端，连接池需要手动配置。

spring:
  redis:
    host: localhost
    port: 6379
    lettuce:
      pool:
        max-active: 8
        max-idle: 8
        min-idle: 0

缓存注解使用

Spring Cache提供了@Cacheable、@CachePut、@CacheEvict等注解，可以轻松实现缓存逻辑。

@Cacheable(value = "users", key = "#id")
public User getUserById(Long id) {
    return userDao.findById(id);
}

这样,当调用getUserById时，先查缓存，缓存没有才执行方法，并将结果缓存，注意，缓存注解默认使用Spring的SimpleKeyGenerator生成key，如果方法参数复杂，可以自定义key。

性能调优

• 连接池调优：合理配置maxActive、maxIdle、minIdle等参数，避免连接创建和销毁的开销，根据并发量调整，一般maxActive设为预期并发连接数的两倍。
• 序列化方式：默认使用JDK序列化，效率低且占用空间大，建议使用Jackson2JsonRedisSerializer或GenericJackson2JsonRedisSerializer，减少序列化开销，同时便于查看缓存数据，快速配置：

@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
    RedisTemplate<String, Object> template = new RedisTemplate<>();
    template.setConnectionFactory(factory);
    Jackson2JsonRedisSerializer<Object> serializer = new Jackson2JsonRedisSerializer<>(Object.class);
    ObjectMapper objectMapper = new ObjectMapper();
    objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
    objectMapper.activateDefaultTyping(LazyValidatorFactory.POLICY_ALL);
    serializer.setObjectMapper(objectMapper);
    template.setDefaultSerializer(serializer);
    return template;
}

• 批量操作：使用pipeline或mget/mset减少网络往返次数，在循环操作缓存时，尽量使用pipeline提交命令，而非逐一发送。
• 缓存过期策略：对不常更新的数据设置较长的过期时间，更新频繁的数据设置较短的时间，或者使用缓存主动失效，在缓存注解中，可以通过@Cacheable的unless属性控制缓存条件，避免缓存不需要的数据。

分布式缓存是Java后端架构的关键组件,选对方案、用好落地方案，能显著提升系统的吞吐量和稳定性，核心记住：Redis做主力，Spring Cache做封装，再配合一致性策略和异常应对，就能构建一个可靠高效的缓存层。

分布式缓存一致性常见问题解答

问：分布式缓存和本地缓存有什么区别？
答：本地缓存存储在JVM内存中，速度接近CPU但容量有限且无法跨实例共享；分布式缓存部署在独立服务器上，容量可弹性扩展，集群内所有节点共享数据，但存在网络延迟，在Java项目中，单机部署且数据量小用本地缓存，集群环境建议用分布式缓存。

问：Java分布式缓存框架哪个好？
答：Redis是首选，因为它的数据结构丰富、持久化稳定、Java客户端生态成熟（Spring Data Redis、Jedis、Lettuce），Memcached性能虽高但功能单一，Ehcache更适合做本地缓存或二级缓存，实际项目绝大多数采用Redis，尤其在高并发场景下表现突出。

问：分布式缓存一致性怎么保证？
答：最常用Cache Aside模式，更新数据库后删除缓存，读时再回写缓存，对于短暂不一致可接受，强一致性则需避免缓存或使用分布式锁，最终一致性方案简单可靠，覆盖大多数场景，配合重试或消息队列即可解决脏数据问题。