spring-boot-starter-data-redis

用spring-boot框架开发时，利用redis作为mybatis二级缓存时，单体框架时，@Cacheable(value = "users", key = "'findAll'")，通常我们可以直接加载到service的方法上，也可以直接加载到控制器上。

当加入dubbo做分布式微服务开始时，这个时候就不能那么随意任性了。dubbo框架，我们可以直接在暴露的服务类上，加上 @Service(version = "1.0.0")就可以提供服务，不用那么蛮烦的配置，确实事半功倍，但是却带来新的问题，比如，在其实现方法上加上 相关的缓存注解时，不会出错，直接导致dubbo框架不工作，如下。

2017-8-9 17:32:02 main DEBUG Finished creating instance of bean 'userServiceImpl'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'org.springframework.context.event.internalEventListenerFactory'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'org.springframework.transaction.config.internalTransactionalEventListenerFactory'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'cacheManager'
2017-8-9 17:32:02 main INFO Registering beans for JMX exposure on startup
2017-8-9 17:32:02 main DEBUG Autodetecting user-defined JMX MBeans
2017-8-9 17:32:02 main DEBUG Unable to locate LifecycleProcessor with name 'lifecycleProcessor': using default [org.springframework.context.support.DefaultLifecycleProcessor@1af05b03]
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'lifecycleProcessor'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'org.springframework.boot.autoconfigure.internalCachingMetadataReaderFactory'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessor'
2017-8-9 17:32:02 main DEBUG Could not find key 'spring.liveBeansView.mbeanDomain' in any property source

那么针对，此类问题我们怎么解决呢？
这个时候，我们可以把注解加载到mapper或者dao的接口上去，问题即可得到解决。

@Mapper
public interface UserDao {

    @Select("select * from t_sys_user where type = 'user_type_1'")
    Dict findUser();
    
    @Select("select * from t_sys_user")
    @Cacheable(value = "users", key = "'findAll'")
    List<Dict> findAll();
}

事实上，我们将redis既然当做Mybatis的二级缓存来用，我们编写程序时，就更应该靠近Mybatis的方法，难到不是不？因此，规范的使用某一种技术是多么的重要！

当然，我们还有其它的解决方式，就是抛弃spring boot的无配置文件，直接采用传统的xml的方法，在service层，直接采用spring的注解，主要一定要换过来，进行配置问题也可以得到解决。

当采用传统的模式和spring 的注解后，我们就可以在service的方法加上缓存的注解了，这样更加贴近我们的心理的想法，毕竟可以很大幅度的提升性能，减少对redis的不断读写的压力。

不过除了上述的两种方式以外，我们也可以直接加载servlet的方法上，或者控制器上面，不过非常慎重，否则不知道又会导致什么意想不到的问题。

当然，如果实在不想使用xml的方式进行配置，可以中间另外加载一层service的中间类，在中间类上面应用rpc的调用，问题也可以得到相应的解决。

导致这个问题，本质原因是因为各个扫描类扫描顺序，以及注解启用的顺序有关，虽然，可以用@Order的方式，进行调控，但是不是很理想。对应此类问题，暂时没有很好的方案解决，需要修改底层的源码，问题是由于各自的特点以及其针对的领域不同和采用实现技术不能而引起，暂时只能几度赤水河，走迂回战术。