这里提到的缓存是通用的缓存，如表格获取时优先查询redis，如果有，则读取 redis 中的数据，如果没有，读取数据库，并将返回结果存入 redis 中，然后新增/修改/删除等操作时，需要将对应的缓存数据清空，以保证每次获取都是最新的数据。当然，有其他需求的时候，也可以直接通过 redisTemplate来对 redis 进行增删改查，这个做法跟 MySQL 等关系型数据库是差不多的，关于 redis 操作的部分因为不是这篇文章的重点，所以这里就不赘述了。

这里的实现思路有两种，第一种是完全通过 spring AOP面向切面编程，给 select 做一层切面，给 save/update/delete 做一层切面，来完成上面说的功能。第二种是Spring的 cache 库(其实还是面向切面的技术)，辅以 spring AOP，可以大大简化切面编程部分代码。

首先是要导入相关 jar 包，我现在项目都是 spring-boot 的，所以jar 包带有 spring-boot 前缀的，如果不是 spring-boot 的，直接找对应 spring 版本就可以了，都是比较通用的 jar 包，也不难找。

<!-- redis —>
<dependency>   
<groupId>org.springframework.boot</groupId>   
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- cache 缓存 —>
<dependency>   
<groupId>org.springframework.boot</groupId>   
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>

首先是cache 和 redis 的配置，我这里将两个配置写在了一个类中

@Configuration
@EnableCaching
@PropertySource(value = "classpath:/application.properties")
public class CacheConfig extends CachingConfigurerSupport {


    /**
     *
     * @return
     */
    @Bean
    public CacheManager cacheManager(RedisTemplate redisTemplate) {
        RedisCacheManager manager = new RedisCacheManager(redisTemplate);
        //设置统一的过期时间
        manager.setDefaultExpiration(120l);
        //可在 map 中给不同的 key 设置对应的过期时间
//        manager.setExpires(new HashMap<String, Long>());
        return manager;
    }

    @Value("${spring.redis.host}")
    String hostName;

    @Value("${spring.redis.password}")
    String password;

    @Value("${spring.redis.port}")
    Integer port;

    @Value("${spring.redis.timeout}")
    Integer timeout;

    @Bean
    JedisConnectionFactory jedisConnectionFactory() {
        JedisConnectionFactory jedisConnectionFactory = new JedisConnectionFactory();
        jedisConnectionFactory.setHostName(hostName);
        jedisConnectionFactory.setPort(port);
        jedisConnectionFactory.setPassword(password);
        jedisConnectionFactory.setDatabase(0);
        jedisConnectionFactory.setTimeout(timeout);
        return jedisConnectionFactory;
    }
}

这个类有几个地方要注意的，首先是类的注解，@configuration 是 spring-boot 将类装配成 bean 的注解，@EnableCaching 是声明开启缓存功能的注解，@PropertySource 是引用配置文件的注解

配置类里面有两个 bean，cacheManager是给 cache 库配置缓存的实际位置，因为 spring-cache 可以搭配的缓存很多，也就有很多cacheManager 可以使用，我们这里用的是 redis，所以用的是 RedisCacheManager。

这里可以给缓存上过期时间，但是这里要注意一下这个过期时间指的是通过 cache类库添加进 Redis 缓存的过期时间，也就是@Cacheable 和@CachePut 这两个注解。如果单独使用 RedisTemplate 添加缓存，是要另外设置过期时间的。另外一个bean是 Redis 的配置方法。
然后简单介绍一下 cache 库，这个库是 Spring的缓存库，使用起来也是非常简单，通过几个使用在类或方法上面的注解即可达成目的

@Cacheable   //通过方法的查找是优先查找缓存,如果找到,方法不会执行,当找不到时会去找数据库,并将返回结果放入缓存
@CachePut     //通过方法的返回值会放入缓存中,无论缓存中是否有值,方法一定会被执行
@CacheEvict   //清除缓存中的一个或多个条目
@Cacheing      //这是一个分组的注解,能够同时应用多个其他的缓存注解

这里只是简单介绍一下这几个注解的含义，这些内容在其他文章中也都有比较详实的说明,这里也不过多的介绍了。

着重要说的是@Cacheable 注解，这个注解是可以达到查找时优先查找缓存，当缓存中没有才去访问数据库功能的，这个功能实际是通过 AOP 来完成的，所以我们也可以自己写相关代码，不过既然有现成的，那直接调用是极好的。

@Cacheable 注解有几个属性，对缓存有着较大的影响(这些属性其实这几个注解都有，但是上面几个注解有缺陷，下面会讲)。

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Cacheable {

    String key() default "";

    String keyGenerator() default "";

    String condition() default "";

    String unless() default "";

}

这里只截取了 Cacheable 注解中部分属性，其他属性具体功效可以看源码，介绍的也都比较详实。因为 redis 是键值对数据库，存储模型都是 key-value 格式的，所以要存入缓存，得要有对应的 key。key 有两种生成方式，第一种是直接指定，这种方式一般用于某些定制化的缓存当中，通用返回接口的缓存得要用第二种方式，也就是通过键生成器来生成缓存的 key。condition 和 unless 的区别是，condition 是条件成立时，存入缓存；unless 是排除值不成立的，存入缓存。这两者看起来是一个意思，但是在逻辑上来说还是有细微差别的，一个是阻止存入缓存(unless)，但是还是会在缓存中查找；另外一个是先判断 condition 的条件(condition)，如果不成立，则不会查找缓存，也不会存入缓存。以上的 key，condition，unless 都是使用的 SpEL 表达式，后面会在实例中有一些简单的介绍，详细的说明也可通过其他文章学习。

在这些属性中，key 的生成格外重要，要能够通用，不必为每个需要用缓存的方法都手动生成 key，又要保证唯一性，因为不止是方法名会影响 key 值，每次调用时参数的不一致 都应该是不同的 key。这里keyGenerator很好的帮我们完成了这样的工作。

可以使用Spring默认的SimpleKeyGenerator来生成 key，但是这个 key 是不会将函数名组合在 key 中，也是有缺陷，所以我们需要自定义一个 keyGenerator。

@Override
public Object generate(Object target, Method method, Object... params) {
        Logger log = Logger.getLogger("Keygenerate");
        StringBuilder key = new StringBuilder();
        key.append(method.getDeclaringClass().getName()).append(".").append(method.getName()).append(":");  //先将类的全限定名和方法名拼装在 key 中
        if (params.length == 0) {
            return key.append(NO_PARAM_KEY).toString();
        }
        for (Object param : params) {   //通过遍历参数,将参数也拼装在 key 中,保证每次获取key 的唯一性
            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 {
                key.append(param.hashCode());   //如果是map 或 model 类型
            }
            key.append('-');
        }
        return key.toString();
    }

我是将实现了 KeyGenerator 的类放在了 Spring 的上下文中，这样子只要是使用了@Cacheable 注解的方法都可以根据规则来生成唯一的 key 了。
当然实际项目中还是有可能是会需要针对特定的方法来生成 key 的，下面给一个实例来说明：

@Cacheable(unless = "#result == '{\"data\":[],\"total_count\":0}'",key = "'keyGenerator' + '.' + #methodName + ':' + #id")

这是一个带有 unless 和 key 的注解，实现的功能是查询，当没有值时不存入缓存。
到此我们已经可以通过注解将获取到的值存入缓存，并直接通过缓存将值获取出来，不用额外的调用数据库了，接下来的工作是当 save/update/delete 等操作时，将相关数据从缓存中清除，以保证获取数据的准确性。

cache 库的注解中是有可以实现这个功能的，@CacheEvict。但是当我们通过 KeyGenerator 来自定义生成 key 时，@CacheEvict 便无法获取对应的 Key，则无法正确清除相关缓存。举个栗子，有用户表和订单表，用户表有一次查询，在缓存中生成这次查询的缓存，订单表也有一次查询，在缓存中生成这次查询的缓存。这时新增一条订单，需要清空订单相关的全部缓存，否则会出现获取数据不一致的情况。但是如果通过@CacheEvict 来做，是无法知道目前 Redis 中关于订单缓存的 Key 的，当然可以全部清空，这样会把用户表的缓存也清空掉，这必然是不好的。

那为了实现相关操作只清空相关的所有缓存，这里采取 AOP 的方式，对 save/update/delete 切面，当有这些操作的时候，就清空对应的缓存。

这里有两种做法，第一种直接将切点设置成save/update/delete，在每次进入方法前删除缓存，但是这种做法一个是得严格限制方法名，另外一个是如果有一些其他方法想要删除缓存，就得要增加切点。所以这里用第二种方法，自定义注解，然后通过检查方法是否带有该注解，来判断是不是需要清空缓存。

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ClearRedis {
}

首先是自定义的缓存，然后在需要用到删除的方法上面使用该缓存即可

@ClearRedis
public String save(User user){...}

这样准备工作就算完成了，接下来是AOP 相关的代码

@Component
@Aspect
public class AspectJConfig {
    @Pointcut("execution(* com.Demo.*.*(..))")
    private void clearCache(){}
    //save 方法前,清空相关 key的缓存
    @Before("clearCache()")
    public void beforeSave(JoinPoint joinPoint) throws Throwable {
        String targetName = joinPoint.getTarget().getClass().getName();
        Class targetClass = Class.forName(targetName);
        Method[] methods = targetClass.getMethods();
        String methodName = joinPoint.getSignature().getName();
        boolean isClearRedisPresent = false;
        for (Method method : methods)
        {
            if (method.getName().equals(methodName))
            {
                if (method.isAnnotationPresent(ClearRedis.class))
                {
                    isClearRedisPresent = true;
                    break;
                }
            }
        }
        if (isClearRedisPresent)
        {
            //获取切点作用的方法
            Signature signature = joinPoint.getSignature();
            MethodSignature methodSignature = (MethodSignature) signature;
            //获取有作用方法前缀的 key,遍历以删除该切点作用方法关联的缓存,因为 save 有刷新数据库
            Set<String> keys = stringRedisTemplate.keys(methodSignature.getDeclaringTypeName() + "*");
            stringRedisTemplate.delete(keys);
            keys = stringRedisTemplate.keys(methodSignature.getDeclaringTypeName() + "*");            
        }
    }
}

由于是通过增加注解的方式，所以切点的范围可以定位到 service 层的所有方法上。逻辑上来说在save/delete/update 前，后删除缓存都是可以的，所以是用@Before 还是@After 或者@Around 都是可以的。

方法体内分为两个部分，第一个部分是判断该切点方法有没有使用@ClearRedis 注解，第二部分是当使用了注解，则清空对应的缓存。这两步都是利用了 JAVA 的反射机制，通过 joinPoint 来找到对应的调用类和调用方法以及调用方法的参数，这样我们就可以根据类+方法名+参数列表来组装对应的 key，这个跟上面在 KeyGenerator 中生成 key 的逻辑是一一对应的。最后是利用的 Redis 的模糊查询的逻辑可删除对应前缀的 Key，也就是我们可以不管参数是多少，是用哪个方法调用的，直接删除指定类获取到的所有缓存。

到此为止所有的部分就介绍完毕了，通过这样的配置，可以简单的在获取方法上增加@Cacheable 注解生成缓存，同时在方法上增加@ClearRedis 来清空类对应的缓存，保证了读的效率，也同时保证的读的准确性。

最后有两点存疑
1.我之前试过用@CacheEvict,想来生成指定的 Key，并通过前缀删除，但是好像做不到，因为前缀删除这个功能是 Redis 的，不是 cache 的。不过我觉得既然 cache 提供这样一个注解，应该不至于做不到这个需求，所以还得再继续看一下。

2.第二个就是如果将切点设置成 service 层所有的方法，会不会对效率有所影响，这个也要在实际的运行环境中检测才行。