想用redis
用户管理系统，编码完成了（包含用户、组织等等功能），但是查询用户列表、组织列表时，发现响应速度比较慢，所以打算使用redis来加快响应速度
开始行动
在用户列表(findAll)，查询单个用户（findById，findByName）等方法上加了缓存，删除、修改等操作删除缓存
问题
不加思索的添加缓存，导致了一个严重的问题。耦合性非常严重
原因
用户管理，有分配组织的功能，也就是说，查询用户列表或者用户详情时，需要查询用户具有的组织信息；同理：也可以向组织添加用户
那么如果对用户列表添加了缓存，如果修改/删除了组织，没有清楚用户管理的缓存，那么用户列表返回的，还是组织未删除/修改前的数据，这就造成脏数据了，不是我们想要的
如果在删除/修改时，清除用户管理的缓存，这样可以实现用户列表数据的实时性，但问题就是：耦合性
组织删除/修改时，为什么要 管 用户的数据呢？ 那要是下次再来一个角色管理，岂不是，在删除/修改角色信息时，又得清除 用户的缓存信息，这是非常严重的耦合问题
所以，决定去掉列表类接口的缓存
改进
既然去掉了列表类接口的缓存，剩下使用场景最多的，也就是查询单个对象了
又有问题
单个对象的查找，主要的作用还是在于，校验这个对象是否存在，无论是修改，删除、停/启用等等，首先都会校验用户是否存在
但是，这种查询，通常都是类内部直接调用，无法被缓存代理控制
原因：缓存注解（@Cacheable ）由AOP 实现，类内部的方法调用类内部的加了缓存注解的方法，并没有通过AOP，因此缓存无法实现
这么看来，要使用缓存，就没有什么意义了
最终，决定去掉缓存
从代码层面进行优化，加快查询速度
注
Springboot 集成的缓存、事物等控制
都是通过AOP来进行处理的，当类内部的方法调用类内部的方法，缓存，事物都是不会生效的，所以，使用Springboot带给我们方便的同时，也要仔细思考，这些注解为什么能够生效，在哪些场合使用才是对的
BTW
现工程也有一个地方使用了redis
OAuth2.0 认证（客户端模式），通过key和secret获取token，是存在redis，因为redis里的数据可以根据配置的时间自动失效，比放数据库和内存中都方便
