【Redis】SSM整合Redis&注解式缓存的使用

欢迎来到我的CSDN主页！

我是Java方文山，一个在CSDN分享笔记的博主。

推荐给大家我的专栏《Redis》。

点击这里，就可以查看我的主页啦！

Java方文山的个人主页

如果感觉还不错的话请给我点赞吧！

期待你的加入，一起学习，一起进步！

目录

一、SSM整合Redis

1.1.pom配置

1.2.配置文件spring-redis.xml

1.3.修改applicationContext.xml

1.4.配置redis的key生成策略

二、Redis的注解式开发及应用场景        

2.1.什么是Redis注解式

2.2.为什么使用Redis注解式

2.3.Redis注解式的应用

①Cacheable

②CachePut

③CacheEvict

2.4.CachePut和Cacheable的区别

三、Redis中的击穿、穿透、雪崩的三种场景

3.1.缓存穿透

1.什么是缓存穿透？

2.如何解决缓存穿透问题？

3.2.缓存击穿

1.什么是缓存击穿？

2.如何解决缓存击穿问题？

3.3.缓存雪崩

1.什么是缓存雪崩？

2.如何解决缓存雪崩问题？

---

一、SSM整合Redis

1.1.pom配置

在Maven或Gradle的构建文件中添加Redis相关的依赖。

注意：resources的配置必须涵盖读取.properties结尾的文件

  4.0.0

  org.example
  ssm2
  1.0-SNAPSHOT
  war

  ssm2 Maven Webapp
  
  http://www.example.com

  
    UTF-8
    1.8
    1.8
    3.7.0

    
    
    5.0.2.RELEASE
    
    3.4.5
    
    5.1.44
    
    5.1.2
    
    1.3.1
    
    2.1.1
    2.4.3
    
    2.9.1
    
    4.12
    4.0.0
    1.18.2

    2.10.0
    1.7.7

    2.9.0
    1.7.1.RELEASE
  

  
    
    
      org.springframework
      spring-context
      ${spring.version}
    
    
      org.springframework
      spring-orm
      ${spring.version}
    
    
      org.springframework
      spring-tx
      ${spring.version}
    
    
      org.springframework
      spring-aspects
      ${spring.version}
    
    
      org.springframework
      spring-web
      ${spring.version}
    
    
      org.springframework
      spring-test
      ${spring.version}
    

    
    
      org.mybatis
      mybatis
      ${mybatis.version}
    
    
    
      mysql
      mysql-connector-java
      ${mysql.version}
    
    
    
      com.github.pagehelper
      pagehelper
      ${pagehelper.version}
    
    
    
      org.mybatis
      mybatis-spring
      ${mybatis.spring.version}
    

    
    
      org.apache.commons
      commons-dbcp2
      ${commons.dbcp2.version}
    
    
      org.apache.commons
      commons-pool2
      ${commons.pool2.version}
    

    
    
    
      org.apache.logging.log4j
      log4j-core
      ${log4j2.version}
    
    
      org.apache.logging.log4j
      log4j-api
      ${log4j2.version}
    
    
    
      org.apache.logging.log4j
      log4j-web
      ${log4j2.version}
    

    
    
      junit
      junit
      ${junit.version}
      test
    
    
      javax.servlet
      javax.servlet-api
      ${servlet.version}
      provided
    
    
      org.projectlombok
      lombok
      ${lombok.version}
      provided
    

    
      org.springframework
      spring-webmvc
      ${spring.version}
    

    
    
      javax.servlet.jsp
      javax.servlet.jsp-api
      2.3.3
    
    
      jstl
      jstl
      1.2
    
    
      taglibs
      standard
      1.1.2
    

    
      commons-fileupload
      commons-fileupload
      1.3.3
    


    
      org.hibernate
      hibernate-validator
      6.0.7.Final
    


    
      com.fasterxml.jackson.core
      jackson-databind
      2.9.3
    
    
      com.fasterxml.jackson.core
      jackson-core
      2.9.3
    
    
      com.fasterxml.jackson.core
      jackson-annotations
      2.9.3
    


    
      org.apache.shiro
      shiro-core
      1.3.2
    

    
      org.apache.shiro
      shiro-web
      1.3.2
    

    
      org.apache.shiro
      shiro-spring
      1.3.2
    

    
      net.sf.ehcache
      ehcache
      ${ehcache.version}
    

    
    
      org.slf4j
      slf4j-api
      ${slf4j-api.version}
    
    
      org.slf4j
      jcl-over-slf4j
      ${slf4j-api.version}
      runtime
    

    
    
      org.apache.logging.log4j
      log4j-slf4j-impl
      ${log4j2.version}
    

    
      redis.clients
      jedis
      ${redis.version}
    
    
      org.springframework.data
      spring-data-redis
      ${redis.spring.version}
    
  

  
    ssm2
    
      
      
        src/main/java
        
          **/*.xml
        
      
      
      
        src/main/resources
        
          *.properties
          *.xml
        
      
    
    
      
        
          org.apache.maven.plugins
          maven-compiler-plugin
          ${maven.compiler.plugin.version}
          
            ${maven.compiler.source}
            ${maven.compiler.target}
            ${project.build.sourceEncoding}
          
        
        
          org.mybatis.generator
          mybatis-generator-maven-plugin
          1.3.2
          
            
            
              mysql
              mysql-connector-java
              ${mysql.version}
            
          
          
            true
          
        

        
          maven-clean-plugin
          3.1.0
        
        
        
          maven-resources-plugin
          3.0.2
        
        
          maven-compiler-plugin
          3.8.0
        
        
          maven-surefire-plugin
          2.22.1
        
        
          maven-war-plugin
          3.2.2
        
        
          maven-install-plugin
          2.5.2
        
        
          maven-deploy-plugin
          2.8.2
        
      
    
  

1.2.配置文件spring-redis.xml

这个配置文件的作用主要用于配置数据源和连接工厂还有配置序列化的用途

redis.properties

redis.hostName=localhost
redis.port=6379
redis.password=123456
redis.timeout=10000
redis.maxIdle=300
redis.maxTotal=1000
redis.maxWaitMillis=1000
redis.minEvictableIdleTimeMillis=300000
redis.numTestsPerEvictionRun=1024
redis.timeBetweenEvictionRunsMillis=30000
redis.testOnBorrow=true
redis.testWhileIdle=true
redis.expiration=3600

spring-redis.xml

 

1.3.修改applicationContext.xml

如果spring配置文件中需要配置两个及以上的properties文件则需要在applicationContext.xml中进行配置处理，否则会出现覆盖的情况。

    
    
        
        
        
            
                classpath:jdbc.properties
                classpath:redis.properties
            
        
    


    
    
    

1.4.配置redis的key生成策略

CacheKeyGenerator.java

package com.zking.ssm.redis;

import lombok.extern.slf4j.Slf4j;
import org.springframework.cache.interceptor.KeyGenerator;
import org.springframework.util.ClassUtils;

import java.lang.reflect.Array;
import java.lang.reflect.Method;

@Slf4j
public class CacheKeyGenerator implements KeyGenerator {
    // custom cache key
    public static final int NO_PARAM_KEY = 0;
    public static final int NULL_PARAM_KEY = 53;

    @Override
    public Object generate(Object target, Method method, Object... params) {
        StringBuilder key = new StringBuilder();
        key.append(target.getClass().getSimpleName()).append(".").append(method.getName()).append(":");
        if (params.length == 0) {
            key.append(NO_PARAM_KEY);
        } else {
            int count = 0;
            for (Object param : params) {
                if (0 != count) {//参数之间用,进行分隔
                    key.append(',');
                }
                if (param == null) {
                    key.append(NULL_PARAM_KEY);
                } else if (ClassUtils.isPrimitiveArray(param.getClass())) {
                    int length = Array.getLength(param);
                    for (int i = 0; i < length; i++) {
                        key.append(Array.get(param, i));
                        key.append(',');
                    }
                } else if (ClassUtils.isPrimitiveOrWrapper(param.getClass()) || param instanceof String) {
                    key.append(param);
                } else {//Java一定要重写hashCode和eqauls
                    key.append(param.hashCode());
                }
                count++;
            }
        }

        String finalKey = key.toString();
//        IEDA要安装lombok插件
        log.debug("using cache key={}", finalKey);
        return finalKey;
    }
}

 

具体生成缓存键的逻辑如下：

1. 首先，将目标对象的简单类名和方法名添加到缓存键中，以方便区分不同的方法。
2. 接下来，根据方法的参数个数进行判断：
   • 如果参数个数为0，则将NO_PARAM_KEY添加到缓存键中，表示没有参数。
   • 如果参数个数大于0，则遍历参数数组，根据参数的类型和取值来生成缓存键的一部分。
3. 在遍历参数数组时，判断参数的类型：
   • 如果参数为null，则将NULL_PARAM_KEY添加到缓存键中，表示参数为null。
   • 如果参数为基本类型数组，则遍历数组中的元素，并将每个元素及其索引添加到缓存键中。
   • 如果参数为基本类型或包装类类型，或者是字符串类型，则直接将参数添加到缓存键中。
   • 如果参数为其他类型，则使用参数对象的哈希码作为缓存键的一部分。
4. 最后，将生成的缓存键转换成字符串，并返回。

在代码中，通过log.debug()语句输出了生成的缓存键，方便调试和查看。

注意事项：

• 为了保证缓存键的唯一性，需要确保目标对象、方法以及参数的哈希码等逻辑正确。可以通过重写对象的hashCode()和equals()方法来确保哈希码的正确性。
• 在使用自定义的缓存键生成器时，需要将其配置为Spring缓存注解的keyGenerator属性的值，以替代默认的缓存键生成器。

二、Redis的注解式开发及应用场景        

2.1.什么是Redis注解式

Redis的注解式是指通过使用Spring框架提供的缓存注解，在业务代码中对Redis进行读写操作的方式。这种方式可以大大简化开发人员对缓存的操作，避免了手动编写Redis API代码的繁琐操作。

Spring框架提供了一系列缓存注解，其中常用的有：

1. @Cacheable: 表示方法的返回值可以被缓存，如果缓存中已经存在相同Key的值，则直接返回缓存中的值，否则会执行方法体中的代码，并将返回值存储到缓存中。

2. @CachePut: 表示将方法的返回值存储到缓存中，常用于更新缓存中的值。

3. @CacheEvict: 表示从缓存中删除指定的Key，常用于删除缓存中的某个值。

4. @Caching: 表示对多个缓存注解进行组合，常用于同时使用多个注解的场景。

5. @CacheConfig: 可以在类级别上设置缓存相关的配置，避免在每个方法上重复设置。

通过使用这些缓存注解，开发人员可以快速方便地实现对Redis的读写操作，同时也能够灵活地控制缓存的过期时间、缓存Key的生成规则等。

2.2.为什么使用Redis注解式

使用缓存注解的主要目的是为了提高应用程序的性能和响应速度。当应用程序从数据库或其他资源中获取数据时，如果这些数据在未来的请求中可能会被多次读取，那么使用缓存可以显著减少每个请求的响应时间。缓存将数据存储在内存中，因此可以快速读取，而不需要每次都访问数据库或其他资源。

使用缓存注解还可以减少对数据库或其他资源的负载，从而减少应用程序的资源消耗。当数据被缓存时，应用程序不需要每次都访问数据库或其他资源，从而减轻了这些资源的负载。

在使用缓存注解时，需要注意该注解的生命周期和缓存策略。缓存的生命周期指定了数据在缓存中存储的时间，而缓存策略则指定了何时应将数据从缓存中删除。通过选择适当的生命周期和缓存策略，可以优化缓存的性能和效率。

总之，使用缓存注解可以显著提高应用程序的性能和响应速度，减少对数据库或其他资源的负载，并优化缓存的性能和效率。

2.3.Redis注解式的应用

首先搞一个test类来进行讲解

package com.zking.ssm.biz;

import com.zking.ssm.model.Clazz;
import com.zking.ssm.util.PageBean;
import org.springframework.cache.annotation.CacheEvict;
import org.springframework.cache.annotation.CachePut;

import java.util.List;
import java.util.Map;

public interface ClazzBiz {
    @CacheEvict(value = "xx",key = "'cid:'+#cid",allEntries = true)
    int deleteByPrimaryKey(Integer cid);

    int insert(Clazz record);

    int insertSelective(Clazz record);

//    xx=cache-cid:1
//    key的作用改变原有的key生成规则
//    @Cacheable(value = "xx",key = "'cid:'+#cid")
    @CachePut(value = "xx",key = "'cid:'+#cid",condition = "#cid > 6")
    Clazz selectByPrimaryKey(Integer cid);

    int updateByPrimaryKeySelective(Clazz record);

    int updateByPrimaryKey(Clazz record);

    List listPager(Clazz clazz, PageBean pageBean);
    List

①Cacheable

使用该注解会将查询结果放入Redis中下一次同样的查询就不会走数据库，而是走Redis.

    @Cacheable(value = "xx",key = "'cid:'+#cid",condition = "#cid > 6")
    Clazz selectByPrimaryKey(Integer cid);

value：缓存位置的一段名称，不能为空
key：缓存的key，默认为空，表示使用方法的参数类型及参数值作为key，支持SpEL
condition：触发条件，满足条件就加入缓存，默认为空，表示全部都加入缓存，支持SpEL 

②CachePut

该注解会将查询结果放入Redis中，类似于更新操作，即每次不管缓存中有没有结果，都从数据库查找结果，并将结果更新到缓存，并返回结果

   @CachePut(value = "xx",key = "'cid:'+#cid")
    Clazz selectByPrimaryKey(Integer cid);

value：缓存的名称，在 spring 配置文件中定义，必须指定至少一个
key：缓存的 key，可以为空，如果指定要按照 SpEL 表达式编写，如果不指定，则缺省按照方法的所有参数进行组合
condition：缓存的条件，可以为空，使用 SpEL 编写，返回 true 或者 false，只有为 true 才进行缓存

③CacheEvict

用来清除用在本方法或者类上的缓存数据

    @CacheEvict(value = "xx",key = "'cid:'+#cid",allEntries = true)
    int deleteByPrimaryKey(Integer cid);

value：缓存位置的一段名称，不能为空
key：缓存的key，默认为空，表示使用方法的参数类型及参数值作为key，支持SpEL
condition：触发条件，满足条件就加入缓存，默认为空，表示全部都加入缓存，支持SpEL
allEntries：true表示清除value中的全部缓存，默认为false

2.4.CachePut和Cacheable的区别

Cacheable和CachePut都是Spring框架中用于缓存的注解，它们的主要区别是：

1. Cacheable用于获取缓存中的数据，如果缓存不存在，就会执行方法并将返回值放入缓存中；而CachePut用于更新缓存中的数据，它每次都会执行方法，并将返回值放入缓存中。

2. Cacheable和CachePut的key生成方式不同，Cacheable默认使用方法的参数作为key，可以通过key属性指定key的生成方式或使用SpEL表达式自定义key的生成方式；而CachePut默认使用Cacheable的默认key生成方式，也可以通过key属性指定key的生成方式。

3. Cacheable和CachePut的Sync属性也不同，Cacheable默认为false，即异步处理；而CachePut默认为true，即同步处理。

因此，Cacheable适用于需要从缓存中获取数据的场景，比如读取数据库中的数据；而CachePut适用于需要更新缓存中的数据的场景，比如写入数据库或者删除数据。

在具体应用场景中，可以根据实际需求选择合适的注解。例如，当我们需要查询用户信息时，可以使用Cacheable注解将查询结果缓存起来，下一次查询同样的信息时，直接从缓存中读取，避免了频繁访问数据库，提高了响应速度；当我们需要修改用户信息时，可以使用CachePut注解将修改后的信息更新缓存，保证缓存与数据库的一致性。

三、Redis中的击穿、穿透、雪崩的三种场景

3.1.缓存穿透

首先，我们来说说缓存穿透。什么是缓存穿透呢？缓存穿透问题在一定程度上与缓存命中率有关。如果我们的缓存设计的不合理，缓存的命中率非常低，那么，数据访问的绝大部分压力都会集中在后端数据库层面。

1.什么是缓存穿透？

如果在请求数据时，在缓存层和数据库层都没有找到符合条件的数据，也就是说，在缓存层和数据库层都没有命中数据，那么，这种情况就叫作缓存穿透。

我们可以使用下图来表示缓存穿透的现象。

造成缓存穿透的主要原因就是：查询某个Key对应的数据，Redis缓存中没有相应的数据，则直接到数据库中查询。数据库中也不存在要查询的数据，则数据库会返回空，而Redis也不会缓存这个空结果。这就造成每次通过这样的Key去查询数据都会直接到数据库中查询，Redis不会缓存空结果。这就造成了缓存穿透的问题。

2.如何解决缓存穿透问题？

既然我们知道了造成缓存穿透的主要原因就是缓存中不存在相应的数据，直接到数据库查询，数据库返回空结果，缓存中不存储空结果。

那我们就自然而然的想到了第一种解决方案：就是把空对象缓存起来。当第一次从数据库中查询出来的结果为空时，我们就将这个空对象加载到缓存，并设置合理的过期时间，这样，就能够在一定程度上保障后端数据库的安全。

第二种解决缓存穿透问题的解决方案：就是使用布隆过滤器，布隆过滤器可以针对大数据量的、有规律的键值进行处理。一条记录是不是存在，本质上是一个Bool值，只需要使用 1bit 就可以存储。我们可以使用布隆过滤器将这种表示是、否等操作，压缩到一个数据结构中。比如，我们最熟悉的用户性别这种数据，就非常适合使用布隆过滤器来处理。

3.2.缓存击穿

如果我们为缓存中的大部分数据设置了相同的过期时间，则到了某一时刻，缓存中的数据就会批量过期。

1.什么是缓存击穿？

如果缓存中的数据在某个时刻批量过期，导致大部分用户的请求都会直接落在数据库上，这种现象就叫作缓存击穿。

我么可以使用下图来表示缓存击穿的线程。

造成缓存击穿的主要原因就是：我们为缓存中的数据设置了过期时间。如果在某个时刻从数据库获取了大量的数据，并设置了相同的过期时间，这些缓存的数据就会在同一时刻失效，造成缓存击穿问题。

2.如何解决缓存击穿问题？

对于比较热点的数据，我们可以在缓存中设置这些数据永不过期；也可以在访问数据的时候，在缓存中更新这些数据的过期时间；如果是批量入库的缓存项，我们可以为这些缓存项分配比较合理的过期时间，避免同一时刻失效。

还有一种解决方案就是：使用分布式锁，保证对于每个Key同时只有一个线程去查询后端的服务，某个线程在查询后端服务的同时，其他线程没有获得分布式锁的权限，需要进行等待。不过在高并发场景下，这种解决方案对于分布式锁的访问压力比较大。

3.3.缓存雪崩

如果缓存系统出现故障，所有的并发流量就会直接到达数据库。

1.什么是缓存雪崩？

如果在某一时刻缓存集中失效，或者缓存系统出现故障，所有的并发流量就会直接到达数据库。数据存储层的调用量就会暴增，用不了多长时间，数据库就会被大流量压垮，这种级联式的服务故障，就叫作缓存雪崩。

我们可以用下图来表示缓存雪崩的现象。

造成缓存雪崩的主要原因就是缓存集中失效，或者缓存服务发生故障，瞬间的大并发流量压垮了数据库。

2.如何解决缓存雪崩问题？

解决缓存雪崩问题最常用的一种方案就是保证Redis的高可用，将Redis缓存部署成高可用集群（必要时候做成异地多活），可以有效的防止缓存雪崩问题的发生。

为了缓解大并发流量，我们也可以使用限流降级的方式防止缓存雪崩。例如，在缓存失效后，通过加锁或者使用队列来控制读数据库写缓存的线程数量。具体点就是设置某些Key只允许一个线程查询数据和写缓存，其他线程等待。则能够有效的缓解大并发流量对数据库打来的巨大冲击。

另外，我们也可以通过数据预热的方式将可能大量访问的数据加载到缓存，在即将发生大并发访问的时候，提前手动触发加载不同的数据到缓存中，并为数据设置不同的过期时间，让缓存失效的时间点尽量均匀，不至于在同一时刻全部失效。

 

​

到这里我的分享就结束了，欢迎到评论区探讨交流！！

如果觉得有用的话还请点个赞吧