前言

  • 该问题最早提出是在9月份开发新院统战项目时提出的,也就是我刚刚搭完第一版后端框架,其中持久层使用的框架是mybatis plus,缓存使用的是sprinboot缓存注解+redis,其中将缓存注解加在service层。
  • 当时在使用mybatis plus并以注解开发时,由于过度使用@One与@Many注解进行属性的封装,例如:
@Select("SELECT id,dept_id,username,nick_name,gender,phone,email,avatar_path,password," +
            "is_admin,enabled,create_by,update_by,pwd_reset_time,create_time,update_time" +
            " FROM sys_user u WHERE u.id = #{id} AND is_deleted=0")
    @Results({
            @Result(column = "id", property = "id"),
            @Result(column = "dept_id", property = "deptId"),
            @Result(column = "dept_id", property = "dept",
                    one = @One(select = "marchsoft.modules.system.mapper.DeptMapper.selectById",
                            fetchType = FetchType.EAGER)),
            @Result(column = "id", property = "roles",
                    many = @Many(select = "marchsoft.modules.system.mapper.RoleMapper.findWithMenuByUserId",
                            fetchType = FetchType.EAGER)),
            @Result(column = "id", property = "jobs",
                    many = @Many(select = "marchsoft.modules.system.mapper.JobMapper.findByUserId",
                            fetchType = FetchType.EAGER))
    })
    UserBO findUserDetailById(Long id);

但是没有考虑到一句@One就是一条新的sql,一句@Many就又是n条sql,在没有缓存的情况下效率是非常低的,这就牵扯到之后的不断探究与讨论了。

探究


选择 springboot + redis 缓存

  • 保持与原先与eladmin相同的缓存方法,通过@CacheConfig与@Cacheable将缓存加在service中,仅仅只缓存以id或某字段为主键的记录(类似数据库中一条一条的数据),不缓存分页查询或自己封装后的数据。同时自己对哪些数据加了缓存,还要需要自己手动去维护。
@Service
@AllArgsConstructor
@CacheConfig(cacheNames = "role")
public class RoleServiceImpl implements IRoleService {

    private final RoleMapper roleMapper;

    @Override
    @Cacheable(key = "'id:' + #p0")
    public Role getOneById(Serializable id) {
        return this.roleMapper.selectById(id);
    }

    @Override
    public List<Role> getRolesById(Serializable id) {
        return roleMapper.getRoleByUser(id);
    }
}
  • 这样加缓存的好处是缓存键值清晰,便于存取和删除,还可以建立缓存的命名空间,使缓存结构清晰易于管理。
    springboot+redis

springboot缓存方式与@One、@Many之间的矛盾

  • 上述的缓存方式虽然很理想,但是会导致@One与@Many的查询无法正常走缓存,首先是@One与@Many方法只能调用mapper层的查询方法(调用service层会报错),这就必须要求@CacheConfig与@Cacheable需要加在mapper层的接口方法上(springboot不建议将缓存加在接口方法上)
    其次即使将缓存注解加在了mapper层上,@One与@Many中所调用的查询方法仍然无法走缓存
  • 原因是@One与@Many在实现原理上并不是直接通过反射真正的去调用所指定的方法,而是与当前目标方法结合在了一起。
    到这里就可以发现第一个令人头疼的地方,就是如果使用原生@One与@Many进行开发时,是必定走不了springboot的缓存方式,这里就需要考虑第二种缓存方式了。

mybatis的二级缓存

  • 能使原生@One与@Many以及其所在的方法走缓存的唯一方式就是使用mybatis的二级缓存,当然mybatis自己实现的缓存是存在项目本身的内存中,这当然不符合我们的要求,这里是结合redis实现ibatis的cache接口来开启二级缓存。
@CacheNamespace(implementation = MybatisRedisCache.class, eviction = MybatisRedisCache.class)
@Component
public interface UserMapper extends BasicMapper<User> {}
  • 但其实使用了mybatis的二级缓存之后,看起来貌似解决了@One与@Many不走缓存的问题,但是却又带了许多其他的小问题:

    mybatis plus的分页插件有的时候显示总条数与总页数为0,但结果数据还有

  • 该问题网上也有提到过,但是唯一的建议就是关闭mybatis的二级缓存,说是二级缓存与分页插件之间有冲突。

    缓存没有命名空间,键名是一串随机数字,不易管理与维护

  • 使用了二级缓存结合redis之后,redis中的缓存就变成了这个样子:
    mybatis 二级缓存 + redis

  • 这相较于原先使用springboot + redis缓存的结果乱了很多,而且根本不知道哪个key到底存了什么。

    二级缓存的自动维护会删除该mapper下的所有缓存

  • 手动通过redis实现ibatis的cache接口有以下几个需要实现的方法:

public class MyRedisCache implements Cache {

    //当前放入缓存的mapper的namespace
    private final String id;

    //必须要有这个构造方法
    public MyRedisCache(String id){
        this.id = id;
    }

    //返回cache唯一标识————即namespace
    @Override
    public String getId() {
        return this.id;
    }

    @Override
    public void putObject(Object key, Object value) {
        System.out.println("key : " + key.toString() + "--- value : " + value.toString());
        //使用redishash类型作为缓存存储模型 key hashkey value
        getRedisTemplate().opsForHash().put(id.toString(), key.toString(), value);
    }

    @Override
    public Object getObject(Object key) {
        return getRedisTemplate().opsForHash().get(id.toString(), key.toString());
    }

    @Override
    public Object removeObject(Object o) {
        return null;
    }

    //清空整个id的所有key缓存,mybatis默认走这个
    @Override
    public void clear() {
        getRedisTemplate().delete(id.toString());
    }

    @Override
    public int getSize() {
        return getRedisTemplate().opsForHash().size(id).intValue();
    }

    private RedisTemplate getRedisTemplate(){
        RedisTemplate redisTemplate = SpringContextHolder.getBean("redisTemplate");
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setHashKeySerializer(new StringRedisSerializer());
        return redisTemplate;
    }
}
  • 其中mybatis二级缓存存储一个记录需要有id与key来标识,其中id就是所在的mapper,key就是键名
    mybatis的二级缓存在遇到删改方法时会自动清理缓存,走的是cache接口中的clear方法,会将该id下(就是该mapper)的所有缓存全部删除,而不是根据具体的某个key去删除缓存。
  • 相较于之前springboot + redis的手动维护缓存,是你删除和更新了某条数据,才仅仅将这条数据的缓存删除,而mybatis二级缓存这样直接清除力度过大,如果说为什么不清单个,原因应该有以下两个:
    • removeObject(Object o)还未实现,这是mybatis自身待完善的地方
    • 由于二级缓存存储时键名是随机的,维护难度过大。
  • 上述就是使用二级缓存时又带来的困扰

不使用@One、@Many注解,手动封装结果,调用service层方法走springboot缓存

  • 这个是讨论的最后一种方式,就是不使用@One、@Many注解直接在mapper层进行数据封装,而是第一次查到主体数据,在业务层再次调用其他service层的方法对剩余属性进行封装,这样调用的其他方法就可以走springboot的缓存方式了,这个方案是一个折中的方案,虽然没有@One、@Many的方便开发效率,但是至少维持了适中的执行效率和便于维护的缓存存储结构与方式。

最终方案


2021年1月10日博主再次参与框架的更新迭代中,并且再次接手框架缓存的解决方案

2021年1月10日晚与同学星星讨论后,定下尝试解决方案——重新实现@One与@Many注解,使新注解可以调用service层/mapper层的方法,从而走springboot缓存,其目标为既可以到达原生@One与@Many的开发效率,又可以使用最理想的缓存存储方案!

  • 幸运的是,我们的初步想法是可行的,通过1天的努力与尝试,运用springboot切面编程的思想与java反射原理开发了新的注解——@Query与@Queries,通过新注解@Query与@Queries实现了原先@One和@Many的效果,最重要的调用的方法是通过反射去真真正正调用了一条方法,因此成功走了springboot的缓存。
    注解源码展示
  • 首先是 @Query
// 重新实现 @One、@Many注解,关联查询注解,用于mapper层查询方法上,仅需关联查询一个属性时,可以直接使用@Query
// 如果需要使用多个@Query,请先使用@Queries套在外层(类似 @Results)参数、作用基本和原@One保持一致
// 既可以用于一对一也可以一对多
//
// @author Wangmingcan
// Date: 2021/01/12 09:35
//
@Documented
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Repeatable(Queries.class)
public @interface Query {

    /** 被关联的列,一般为id,请保证和实体类中属性名称一致,驼峰下划线都可以
     * 如关联的列为dept_id,填deptId和dept_id都可以*/
    String column() default "";

    /** 关联的属性 ,和实体类中需要封装的属性名称保持一致*/
    String property() default "";

    /** 执行的查询方法,建议填写mapper层的全限定方法名 ,方法返回值必须和property类型一致*/
    String select() default "";

}
  • 其次是 @Queries
//
// 多个关联查询注解,用于mapper层查询方法上
// 使用方法类比 @Results ,里面套多个 @Query
//  Queries({
//        @ Query(),@Query(),...
//  })
//
// Date: 2021/01/12 09:35
//
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public @interface Queries {

    Query[] value() default {};

}
  • 最后是注解的具体实现
// Query注解具体实现
//
// Date: 2021/01/12 09:35
//
@Aspect
@Component
public class QueryAspect {

    /** Query注解配置切面织入点 */
    @Pointcut("@annotation(marchsoft.annotation.Query)")
    public void queryPointcut() {}

    /** Queries注解配置切面织入点 */
    @Pointcut("@annotation(marchsoft.annotation.Queries)")
    public void queriesPointcut() {}

    //
    // Date :  2021-01-12 09:50
    // @param joinPoint 切入点
    // @param result 目标方法返回值
    // 方法执行后切入并修改目标方法返回值
    //
    @AfterReturning(value = "queryPointcut()", returning = "result")
    public void queryAround(JoinPoint joinPoint, Object result)  {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method signatureMethod = signature.getMethod();
        Query query = signatureMethod.getAnnotation(Query.class);
        //如果目标方法返回类型为 Collection的实现类,如List,则通过迭代器遍历
        //如果目标方法返回类型为 IPage,则先获取getRecords()的List,再通过迭代器遍历
        if (result instanceof Collection || result instanceof IPage) {
            Iterator iter;
            if (result instanceof Collection) {
                iter = ((Collection) result).iterator();
            }else {
                iter = ((IPage) result).getRecords().iterator();
            }
            while(iter.hasNext()){
                execute(query, iter.next());
            }
        }else { //如果目标方法返回类型即为实体类
            execute(query, result);
        }
    }

    @AfterReturning(value = "queriesPointcut()", returning = "result")
    public void queriesAround(JoinPoint joinPoint, Object result)  {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method signatureMethod = signature.getMethod();
        Queries queries = signatureMethod.getAnnotation(Queries.class);
        if (result instanceof Collection || result instanceof IPage) {
            Iterator iter;
            if (result instanceof Collection) {
                iter = ((Collection) result).iterator();
            }else {
                iter = ((IPage) result).getRecords().iterator();
            }
            while(iter.hasNext()){
                Object o = iter.next();
                //针对每个实体处理多个@query
                for (Query query : queries.value()) {
                    execute(query, o);
                }
            }
        }else {
            for (Query query : queries.value()) {
                execute(query, result);
            }
        }
    }

    //
    // Date : 2021-01-11 15:38
    // @param query 注解query
    // @param result 目标方法返回值
    //
    private void execute(Query query, Object result) {
        //获取需要被赋值的属性
        String property = query.property();
        //获取需要执行的方法
        String select = query.select();
        //获取关联的列,并转驼峰
        String column = StringUtils.toCamelCase(query.column());
        //关联属性的类型(也为select的参数类型)
        Class<?> columnType;
        //关联列的值
        Serializable columnValue;
        //select方法返回值类型
        Class<?> selectMethodReturnType;
        //select方法返回结果
        Object selectResult;
        try {
            //目标方法返回值类型class
            Class<?> resultClass = result.getClass();
            //通过反射获取get方法并调用来获取关联列的值
            try {
                Method getMethod = resultClass.getMethod("get" +
                        column.substring(0, 1).toUpperCase() + column.substring(1));
                columnValue = (Serializable) getMethod.invoke(result);
                columnType = getMethod.getReturnType();
            }catch (NoSuchMethodException get) {
                throw new BadRequestException("找不到get方法 : " + get.getMessage() +
                        ",请检查column参数" + column + "是否填写正确");
            }
            //通过反射获取该select方法所在的类
            int pointIndex = select.lastIndexOf(".");
            Class<?> selectMethodClass = Class.forName(select.substring(0, pointIndex));
            //通过反射获取需要调用的select方法
            try{
                Method selectMethod = selectMethodClass.getMethod(select.substring(pointIndex+1), columnType);
                //调用并获取select方法的结果
                selectResult = selectMethod.invoke(SpringContextHolder.getBean(selectMethodClass),
                        columnValue);
                selectMethodReturnType = selectMethod.getReturnType();
            }catch (NoSuchMethodException selectExc) {
                throw new BadRequestException("找不到select方法 : " + selectExc.getMessage() +
                        ",请检查select方法的名称和参数类型");
            }
            //通过反射获取set方法并调用来完成赋值
            try{
                Method setMethod = resultClass.getMethod("set" +
                        property.substring(0, 1).toUpperCase() + property.substring(1), selectMethodReturnType);
                setMethod.invoke(result, selectResult);
            }catch (NoSuchMethodException set) {
                throw new BadRequestException("找不到set方法 : " + set.getMessage() +
                        ",请检查" + property + "的类型与方法" + select + "的返回值是否一致");
            }
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}
  • 其中字符串转驼峰的toCamelCase方法来自StringUtils工具类,获取调用select中需要传入的service/mapper实例通过SpringContextHolder来获取。
  • 其中对IPage的判断是使用了mybatis plus的分页插件的情况下需要考虑的一种情况,如果没有使用mybatis plus或者是其分页插件,把对IPage的判断去除即可。
@Select("SELECT id,dept_id,username,nick_name,gender,phone,email,avatar_path,password," +
            "is_admin,enabled,create_by,update_by,pwd_reset_time,create_time,update_time" +
            " FROM sys_user u WHERE u.id = #{id} AND is_deleted=0")
    @Results({
            @Result(column = "id", property = "id"),
            @Result(column = "dept_id", property = "deptId"),
    })
    @Queries({
            @Query(column = "id", property = "roles",
                    select = "marchsoft.modules.system.mapper.RoleMapper.findWithMenuByUserId"),
            @Query(column = "id", property = "jobs",
                    select = "marchsoft.modules.system.mapper.JobMapper.findByUserId"),
            @Query(column = "dept_id", property = "dept",
                    select = "marchsoft.modules.system.mapper.DeptMapper.selectById")
    })
    UserBO findUserDetailById(Long id);
  • 加缓存方式与原先一致:
@Component
@CacheConfig(cacheNames = "dept")
public interface DeptMapper extends BasicMapper<Dept> {

    @Cacheable(key = "'id:' + #p0")
    Dept selectById(Long id);
}
  • 无论返回结果是UserBO,还是List,还是Set,还是IPage,最终的查询结果都是和原先使用@One与@Many的时候是一致的,而且缓存存储结构与以前也是一样的:
    @Query+redis

总结

  • 上述就是目前想到并实现的最佳缓存解决方案,即具备了原先@One、@Many注解的开发效率,又保留了缓存的存储结构,虽然仍然需要手动维护缓存,但和学长一致认为这是合理的,谁对哪一个方法加了缓存,就有义务自己去维护他,况且难度也比较低。
  • 但上述注解仅仅是实现了原有@One、@Many的最基本的查询封装功能,类似于@Many的fetchType = FetchType.EAGER/LEAZY等功能还需后续不断继续完善。
  • 自此,长达数月的缓存大问题拉下帷幕。

缓存的添加与维护

  • springboot缓存注解的复习————SpringBoot2.0的@Cacheable(Redis)缓存失效时间解决方案
  • 根据上述所说可知,我们是把缓存注解加在了mapper层,所以首先我要说明同时在service层和mapper加缓存时的问题:
    service与mapper加相同的命名空间时,即CacheConfig(cacheNames = "xx")相同,此时会将service和mapper缓存合并,但是如果出现service和mapper中缓存的键名相同,即@Cacheable(key = "XXX")相同,此时service层的覆盖mapper层的缓存。
  • 所以如果出现了缓存加在service和mapper层都可以的情况,我们考虑优先加在mapper层(考虑之后其他的mapper层可能会通过@Query调用)。但是service层也要加命名空间CacheConfig(cacheNames = "xx"),考虑有可能会在service层加其他缓存。但是删除缓存的操作均在service层
  • 下面我以用户user与岗位job(多对多)两个实体类来详细说明缓存的添加与维护。

情况一:单一实体缓存,key和value都仅与该实体相关(1:1)

  • 首先是针对一个实体的单条信息进行缓存,key和value都和一个实体有关。如缓存job表的每一条记录,以id和键名,Job实体为value存入缓存:
    在JobMapper加上命名空间 @CacheConfig(cacheNames = "job")
  • 首先在JobMapper加上命名空间:
@CacheConfig(cacheNames = "job")
public interface JobMapper extends BasicMapper<Job> {
  • 虽然BaseMapper已经提供了根据id查询—— T selectById(Serializable id);
    重写selectById,并加上@Cacheable
  • 但是咱们需要加上缓存,所以需要重新在mapper层写该方法(无需写sql),并加上@Cacheable,此时键名key的命名规则为统一的 "'id:' + #p0" ,id指Job的id,#p0指方法的第一个参数:
@Cacheable(key = "'id:' + #p0")
Job selectById(Long id);
  • 此时springboot会将第一查询的结果放入缓存,之后无论是从service调mapper的该方法,还是从mapper的@Query中调用该方法都可以走缓存。
  • 缓存情况如下图:

    将键名除id外以静态变量存入CacheKey
  • 可以看到我们成功把id为1的job存入了redis缓存,该缓存的value即为Job实体类,键名为 job::id:1 ,其中为了后期维护缓存方便,我们将字符串 "job::id:" 作为静态变量存入 CacheKey.class中,在做维护时只需拼接一个id即可:
public interface CacheKey {
    /**
     * 用户
     */
    String USER_ID = "user::id:";
    /**
     * 数据
     */
    String DATA_USER = "data::user:";
    /**
     * 菜单
     */
    String MENU_ID = "menu::id:";
    String MENU_USER = "menu::user:";
    String MENU_ROLE = "menu::role:";
    /**
     * 角色授权
     */
    String ROLE_AUTH = "role::auth:";
    String ROLE_USER = "role::user:";
    /**
     * 角色信息
     */
    String ROLE_ID = "role::id:";
    /**
     * 部门信息
     */
    String DEPT_ID = "dept::id:";
    String DEPT_ROLE = "dept::role:";
    /**
     * 岗位信息
     */
    String JOB_ID = "job::id:";      //示例
    String JOB_USER = "job::user:";
}

在对应的service层手动维护缓存

  • 这里为了统一建议手动维护缓存,即在JobServiceImpl下手写一个方法来清理缓存,在相应的更新、删除Job的地方调用该方法即可:

    /**
     * 清理缓存
     * @param id job_id
     */
private void delCaches(Long id){
    redisUtils.del(CacheKey.JOB_ID + id);
}
  • 你也可以在相应的更新、删除的方法上加上springboot删除缓存的注解(不推荐,后期缓存情况复杂)
@CacheEvict(key = "'id:' + #p0.id")
public void update(Job resources) {}

对于单一实体的缓存,仅缓存 selectById方法,对于该实体的分页查询等其他条件查询一般不做缓存,除非有特殊要求

情况二:缓存内容关联两个及以上的实体(1:n,n:m)

  • 这类缓存是比较令人头疼的地方,我们之前有规定,@Query中所调用的方法必须要有缓存,这里user与job是多对多的关系,有一张中间sys_users_jobs,当我们在查询一个用户时要连带将其所有的岗位也查找出来:
//UserMapper中查询一个用户
@Select("SELECT id,dept_id,username,nick_name,gender,phone,email,avatar_path,password," +
            "is_admin,enabled,create_by,update_by,pwd_reset_time,create_time,update_time" +
            " FROM sys_user u WHERE u.id = #{id} AND is_deleted=0")
    @Results({
            @Result(column = "id", property = "id"),
            @Result(column = "dept_id", property = "deptId"),
    })
    @Queries({
            @Query(column = "id", property = "roles",
                    select = "marchsoft.modules.system.mapper.RoleMapper.findWithMenuByUserId"),
            @Query(column = "id", property = "jobs",
                    select = "marchsoft.modules.system.mapper.JobMapper.findByUserId"),  //这里
            @Query(column = "dept_id", property = "dept",
                    select = "marchsoft.modules.system.mapper.DeptMapper.selectById")
    })
    @Cacheable(key = "'id:' + #p0")
    UserBO findUserDetailById(Long id);
  • 既然通过@Query调用了JobMapper.findByUserId方法,我们就需要对其加缓存(其他的同理)
//JobMapper中根据用户id查询岗位
@Select("SELECT j.id, j.name, j.enabled, j.job_sort, j.create_by, j.update_by, j.create_time, j.update_time " +
            "FROM sys_job j, sys_users_jobs uj WHERE j.id = uj.job_id AND uj.user_id = ${id} AND j.is_deleted=0")
@Cacheable(key = "'user:' + #p0")
Set<Job> findByUserId(Long id);
  • 此时缓存的命名规则为 key = "'user:' + #p0" ,这里的user指user_id的意思,后面的参数#p0就是user_id,我们可以发现此时的redis里缓存全称为: job::user:2

  • 意思即为user_id为2的用户所拥有的job,从value中可以看出该用户有两个job。我们也需要将 "job::user:" 存入 CacheKey中,命名为 JOB_USER (可以回看上面的)。

    从每个与该缓存相关的实体的service层对其进行维护

  • 以 job::user:2 缓存维护为例

    Job发生删改时,可能需要对改缓存进行维护

  • 当我们修改了一个id为1的job,可能id为2的user有这个job,也可能没有,有的话必须删除该缓存,即我们需要通过sys_users_jobs关系表找到含有job_id=2的user_id的集合,是一个List

//UserMapper下
//根据job_id查询用户Id (清理job缓存时调用)
@Select("SELECT user_id FROM sys_users_jobs WHERE job_id = #{id} group by user_id")
List<Long> findByJobId(Long id);
  • 注意,这里是因为job的变动导致需要清理该缓存,所以该部分清理缓存的代码写在 JobServiceImpl下的delcache方法中:
//JobServiceImpl
private void delCaches(Long id){
    List<Long> userIds = userMapper.findByJobId(id);
    redisUtils.delByKeys(CacheKey.JOB_USER, new HashSet<>(userIds)); //第二种情况所删的缓存
    redisUtils.del(CacheKey.JOB_ID + id);   //第一种情况所删的缓存
}

当中间表sys_users_jobs发生变动时,一定要清理缓存!

  • 当我们修改了user的job时,如上图user_id = 2的用户有两个job,我们将其调整为一个job,此时也需要删除 job::user:2 这条缓存,由于是因为更新了user才导致删除这条缓存,所以该部分代码写在 UserServiceImpl的更新、删除中:
//UserServiceImpl下的更新user方法
public void updateUserWithDetail(UserInsertOrUpdateDTO userInsertOrUpdateDTO) {
//...
//如果岗位发生变化
   if (! CollectionUtils.isEqualCollection(jobIds, userInsertOrUpdateDTO.getJobs())) {
      //...
      //清除缓存
      redisUtils.del(CacheKey.JOB_USER + userInsertOrUpdateDTO.getId());
   }
//...
}
  • 这样,我们才算是对 job::user:2这条缓存做了完全的维护。

对于情况一的缓存只涉及一个实体(表),缓存维护比较好实现,针对第二种情况需要我们考虑全面,在哪些地方需要去维护,这个需要考虑清除,不要随意加缓存

谁加了哪个缓存,谁就有义务去维护它!

最后修改:2021 年 09 月 14 日