Redis在SpringBoot中遇到的问题：预热，雪崩，击穿，穿透
缓存预热
预热即在产品上线前，先对产品进行访问或者对产品的Redis中存储数据。
原因：
1. 请求数量较高
2. 主从之间数据吞吐量较大，数据同步操作频度较高,因为刚刚启动时，缓存中没有任何数据
解决方法：
1. 使用脚本程序固定触发数据预热过程
2. 如果条件允许，使用了CDN（内容分发网络），效果会更好
缓存预热就是系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查 询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据
缓存雪崩
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来 巨大压力。
解决方案：
给不同的Key的TTL添加随机值 （使key不会在同一时间段内大量失效）
利用Redis集群提高服务的可用性 （即利用Linux进行集群部署，一台redis失效还有更多linux补上）
给缓存业务添加降级限流策略
给业务添加多级缓存
缓存击穿
缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无 数的请求访问会在瞬间给数据库带来巨大的冲击。
常见的解决方案有两种： 互斥锁、逻辑过期
缓存击穿的原因：
当一个线程访问A时，它会先来到缓存访问，本来在缓存中没找到时，它会到数据库中访问并把A返回到缓存中。但是！当第一个线程1还没有从缓存离开，线程2，3，4，都来访问A，这时2，3，4会被阻拦在缓存外，因为1还没访问完。1访问结束后去数据库了，才到2，3，4结果他们也没在缓存中找到，就会都去数据库，这时数据库的压力就会变大。
互斥锁
因为锁能实现互斥性。假设线程过来，只能一个人一个人的来访问数据库，从而避免对于数据库访问压 力过大，但这也会影响查询的性能，因为此时会让查询的性能从并行变成了串行，我们可以采用 tryLock方法 + double check来解决这样的问题。
逻辑过期
我们把过期时间设置在 redis的value中，注意：这个过期时间并不会直接作用于redis，而是我们后续 通过逻辑去处理。假设线程1去查询缓存，然后从value中判断出来当前的数据已经过期了，此时线程1 去获得互斥锁，那么其他线程会进行阻塞，获得了锁的线程他会开启一个 线程去进行 以前的重构数据 的逻辑，直到新开的线程完成这个逻辑后，才释放锁， 而线程1直接进行返回，假设现在线程3过来访 问，由于线程线程2持有着锁，所以线程3无法获得锁，线程3也直接返回数据，只有等到新开的线程2把 重建数据构建完后，其他线程才能走返回正确的数据
缓存穿透
缓存穿透 ：
缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这 些请求都会打到数据库。
常见的解决方案有：
缓存空对象
优点：实现简单，维护方便
缺点：额外的内存消耗 可能造成短期的不一致
我们客户端访问不存在的数据时，先请求redis，但是此时redis中没有数据， 此时会访问到数据库，但是数据库中也没有数据，这个数据穿透了缓存，直击数据库，我们都知道数据 库能够承载的并发不如redis这么高，如果大量的请求同时过来访问这种不存在的数据，这些请求就都会 访问到数据库，简单的解决方案就是哪怕这个数据在数据库中也不存在，我们也把这个数据存入到redis 中去，这样，下次用户过来访问这个不存在的数据，那么在redis中也能找到这个数据就不会进入到缓存 了