使用redis的感受

想用redis

用户管理系统，编码完成了（包含用户、组织等等功能），但是查询用户列表、组织列表时，发现响应速度比较慢，所以打算使用redis来加快响应速度

开始行动

在用户列表(findAll)，查询单个用户（findById，findByName）等方法上加了缓存，删除、修改等操作删除缓存

问题

不加思索的添加缓存，导致了一个严重的问题。耦合性非常严重

原因

用户管理，有分配组织的功能，也就是说，查询用户列表或者用户详情时，需要查询用户具有的组织信息；同理：也可以向组织添加用户

那么如果对用户列表添加了缓存，如果修改/删除了组织，没有清楚用户管理的缓存，那么用户列表返回的，还是组织未删除/修改前的数据，这就造成脏数据了，不是我们想要的

如果在删除/修改时，清除用户管理的缓存，这样可以实现用户列表数据的实时性，但问题就是：耦合性

组织删除/修改时，为什么要 管 用户的数据呢？ 那要是下次再来一个角色管理，岂不是，在删除/修改角色信息时，又得清除 用户的缓存信息，这是非常严重的耦合问题

所以，决定去掉列表类接口的缓存

改进

既然去掉了列表类接口的缓存，剩下使用场景最多的，也就是查询单个对象了

又有问题

单个对象的查找，主要的作用还是在于，校验这个对象是否存在，无论是修改，删除、停/启用等等，首先都会校验用户是否存在

但是，这种查询，通常都是类内部直接调用，无法被缓存代理控制
原因：缓存注解（@Cacheable ）由AOP 实现，类内部的方法调用类内部的加了缓存注解的方法，并没有通过AOP，因此缓存无法实现

这么看来，要使用缓存，就没有什么意义了

最终，决定去掉缓存
从代码层面进行优化，加快查询速度

注

Springboot 集成的缓存、事物等控制
都是通过AOP来进行处理的，当类内部的方法调用类内部的方法，缓存，事物都是不会生效的，所以，使用Springboot带给我们方便的同时，也要仔细思考，这些注解为什么能够生效，在哪些场合使用才是对的

BTW

现工程也有一个地方使用了redis
OAuth2.0 认证（客户端模式），通过key和secret获取token，是存在redis，因为redis里的数据可以根据配置的时间自动失效，比放数据库和内存中都方便