“小明，多系统的session共享，怎么处理？”“Redis缓存啊！”“小明，我想实现一个简单的消息队列？”“Redis缓存啊！”
“小明，分布式锁这玩意有什么方案？”“Redis缓存啊！”“小明，公司系统响应如蜗牛，咋整？”“Redis缓存啊！”
本着研究的精神，我们来分析下小明的第四个问题。
准备：
Idea.03/Gradle6.0.1/Maven3.6.3/JDK11.0.4/Lombok0.28/SpringBoot2.2.4RELEASE/mybatisPlus3.3.0/Soul2.1.2/
Dubbo2.7.5/Druid1.2.21/Zookeeper3.5.5/Mysql8.0.11/Vue2.5/Redis3.2
难度：新手--战士--老兵--大师
目标：
Spring优雅整合Redis做数据库缓存步骤：
1先说结论
Redis缓存不是金弹，若系统DB毫无压力，系统性能瓶颈不在DB上，不建议强加缓存层！
1.增加业务复杂度：同一缓存必须被全部相关方法所覆盖，如订单缓存，只要涉及到订单数据更新的方法都要进行缓存逻辑处理。
同时，KV存储时，因各方法返回的类型不同，这样就需要多个缓存池，但各方法后台的数据又存在关联，往往导致一个方法需
要处理关联的多个缓存，从而形成网状处理逻辑。
2.存在并发问题：缓存没有锁机制，B线程进行DB更新，同时A线程请求数据，缓存中存在即返回，但B线程还未更新到缓存，导
致缓存与DB不一致；或者A线程B线程都进行DB更新，但写入缓存的顺序发生颠倒，也会导致缓存与DB不一致，请看官君想想如何解决；
3.内存消耗：小数据量可直接全部进内存，但海量数据不可能全部直接进入Redis，机器吃不消！可考虑只缓存DB数据索引，然后配合
“布隆过滤器”拦截无效请求，有效请求再去DB查询；
4.缓存位置：缓存注解的方法，执行时序上应尽量靠近DB，远离前端，如放dao层，请看官君思考下为啥。
适用场景：1.确认DB为系统性能瓶颈，2.数据内容稳定，低频更新，高频查询，如历史订单数据；3.热点数据，如新上市商品；
2步骤
2.1原理
这里我说的是注解模式，有四个注解，SpringCache缓存原理即注解+拦截器
org.springframework.cache.interceptor.CacheInterceptor
对方法进行拦截处理：
Cacheable：可标记在类或方法上。标记在类上则缓存该类所有方法的返回值。请求方法时，先在缓存进行key匹配，存在则直接取缓存数据并返回。主要参数表：CacheEvict：从缓存中移除相应数据。主要参数表：CachePut：方法支持缓存功能。与Cacheable不同的是使用CachePut标注的方法在执行前不会去检查缓存中是否存在之前执行过的结果，而是每次都会执行该方法，并将执行结果以键值对的形式存入指定的缓存中。主要参数表：
Caching:多个Cache注解组合使用,比如新增用户时，同时要删除其他缓存，并更新用户信息缓存，即以上三个注解的集合。2.2编码
项目有五个微服务，我仅改造了customer服务模块：
引入依赖，build.gradle文件：
Redis配置项，resources/config/application-dev.yml文件：
文件：