springboot缓存之redis整合的方法
默认使用的是ConcurrentMapCacheManager的ConcurrentMapCache作为缓存组件。
使用ConcurrentMap的时候，是将数据保存在ConcurrentMap<Object,Object>当中的。
实际在开发过程中，我们经常使用的，是一些缓存中间件的。
比如我们经常使用的redis，memcache，包括我们使用的ehcache，等等，我们都是使用一些缓存中间件。
我们之前讲解原理的时候，也发现了，springboot是支持很多的缓存配置的：
如下图所示的：
默认开始的配置的是：SimpleCacheConfiguration。
其他的缓存是在什么时候开启呢？
我们可以ctrl+n搜索一下，这些配置类，然后进去看看他们的conditional条件：
这些都是表示，当你导入了相应的包的时候，这些配置才会是生效的哦。
整合redis作为缓存
如果有不会redis这个技术的同学，尚硅谷当中有周阳老师发布的redis系列的讲解视频。或者大家可以最快地访问redis的官方网站，来进行学习，redis.cn是redis学习的中文网。
安装redis
搜索redis镜像
这个是连接国外的仓库，速度是比较慢的。
我们推荐使用docker 中国。
docker pull registry.docker-cn.com/library/redis
启动redis镜像
docker run -d -p 6379:6379 --name myredis [REPOSITORY] docker ps登录后复制
为了测试，打开redis的连接工具。
redis desktop manager
测试redis常用的数据操作
redis操作list
redis的set操作
引入redis的starter
配置redis
简单说下redis原理
我们引入了redis的starter之后，redisAutoConfiguration就起作用了。
这个RedisAutoConfiguration是给容器当中加入了两个组件：
给容器中加入的组件，一个是叫做RedisTemplate，一个是叫做StringRedisTemplate，两个东西。
这两个东西就是用来操作redis的。
这就跟大家以前用的jdbcTemplate一样，用来操作数据库的东西。
这就是spring用来简化操作redis的两个template，如果在程序当中想要用这两个东西，就自动注入就可以了。
redis测试
redis操作list：
redis测试保存对象
这些看不懂的玩意，全部都是序列化的结果。
redisTemplate默认的序列化规则
默认的序列化器，就是使用的JdkSerializationRedisSerializer。
默认的序列化器，就是使用的JDK的序列化器。
我们来切换成json的序列化器，就可以了。
redis配置
在测试类当中，自动注入我们自己配置的redisTemplate。
然后我们再次测试保存对象。
这就说明了，我们的序列化器修改成功了。
这就说明白了，如果我们后面要保存对象的时候，我们经常是要修改序列化器的。
测试缓存
我们之前使用的是ConCurrentMap的缓存管理器的。
这个缓存管理器，帮我们来创建出来缓存组件的。
缓存组件来实际给缓存中，进行CRUD的工作的。
现在我们引入了redis之后，会发生什么样的效果呢？
我们还是在application.properties当中将debug=true，这样就可以将自动配置报告来打开。
这样的时候，我们重新启动我们的程序，在控制台当中，我们去搜索一下。
看看是哪一个自动配置类，是生效的呢？
原来默认开启的是：SimpleCacheConfiguration的。
现在我们引入了redis相关的starters之后，程序默认开启的是RedisCacheConfiguration了。
启动程序，直接进行测试就可以了。
说明第一次查询的时候，是查询数据库了。
第二次查询的时候，控制台是没有任何输出的，说明是查询了缓存了。
缓存默认是只有redis开启的。
那么肯定是在redis当中了。
我们可以查看一下：
这个说明一个问题，在k和v都是object的时候，默认保存对象的时候，利用序列化来保存的。我们是想要让redis自动保存为json的。
我们应该怎么做呢？
我们先来分析一下这些过程当中的原理。
1、我们是引入了redis的starter，所以我们的cachemanager变为了rediscachemanager了，
2、默认创建的rediscachemanager在操作我们的数据的时候，传入了一个redistemplate的东西。
3、这个redistemplate是redisautoconfiguration帮我们创建的。这个redistemplate默认使用的序列化机制是jdkserializationredisserializer的。这个就是相当于，redis默认给我们防止的redisCacheManager还不太符合我们的要求的。
我们怎么办呢？
我们应该自定义CacheManager的。
自定义redisCacheManager
这个时候，我们再启动项目，来进行测试，这个时候，我们就可以看到redis当中的结果，是我们想要的了。
韫秋下次面试的时候，就可以问那些想要来软件园的人，说，你知道redis starter保存对象的时候，redisTemplate默认的序列化规则是什么吗？
如果我们在使用redis的过程中，我们想要修改默认的序列化规则，我们应该怎么做呢？
我们可以自定义redisCacheManager，然后自定义redisTemplate，在redisTemplate当中传入json相关的序列化器的哦。
遗留的小问题
数据库
我们在数据库当中的，department表当中，放进去一条数据：
mapper
我们写一个对应的department操作的mapper。
service
我们再写一个对应的service
controller
启动项目测试
然后我们看看redis当中，是否是有数据的呢？
我们看了，redis当中dept相关的数据，是有的。
我们第二次来查询dept的时候，就应该走缓存redis了。
但是我们第二次去查询的，时候，出现了下面的错误。
错误
上面报错的意思就是说，不能够去读取json的。
因为是要把部门的json对象，转换成为员工的json对象，这是不可以的。
这个就是因为，我们放置的redisCacheManager是操作员工的。
所以，现在我们看到的这个效果，就是很神奇的哦。
缓存的数据，能够存入到redis当中。
但是我们第二次从缓存中查询的时候，就不能够反序列化回来了。
原来就是，我们存的是dept的json的数据，我们的cachemanager，默认是用employee的template来操作redis的。
这个东西只能够将employee的数据反序列化过来的。
解决错误
这个时候，就等于有了2个redisCacheManager了，我们用哪个呢？
我们在service当中，是可以指定的。
然后我们重启项目，结果是报错了：
如果，我们是有多个cacheManager的话，我们一定是要把某一个cacheManager作为，我们的默认配置的缓存管理器的。
比如，我们可以进行下面的操作，来修复这个启动报错的内容的呢：
重新启动进行项目测试
这个时候，看看，我们在进行第二次部门查询的时候，能不能够正常地，成功地，从redis当中反序列化地读取到，我们的部门信息呢？
这个时候，我们就发现，不管是员工还是部门，我们都是可以从redis当中反序列化成功查询的。
这个就是很完美的啦。
编码的方式操作缓存
前面我们说的，全部都是使用注解的方式，来给缓存当中，来放置数据的。
但是，在开发当中，我们经常会，遇到这样的情况。
就是，我们开发进行到某个阶段，我们是需要将一些数据，放到缓存当中的。
我们是需要，使用编码的方式，来操作缓存的。
比如我们在查询出来了部门的信息之后，就希望把这个信息，放入到redis当中。
我们可以把部门的cacheManager注入进来。
然后我们在编码的过程中，可以通过操作这个cacheManager来获取缓存，
然后，再操作缓存组件，来对数据进行增删改查。
我们对上面的代码，启动项目进行测试，发现是可以的，是成功地给redis当中放进去了数据的：
