持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第7天，点击查看活动详情
前言
缓存的使用过程中会出现一些问题，redis作为缓存中的一员，同样面临这些问题，提前了解，我们可以避免很多不必要的坑，同时采用对应的方案进行处理，使我们对缓存的使用更加的得心应手。
缓存预热
缓存预热，即字面意思，对缓存数据进行预先加载或者热加载，通常有三种方式来处理：
- 直接写个缓存刷新页面，上线前手工操作一下
- 数据量不大的时候，可以在项目启动的时候自动加载
- 定时刷新缓存
缓存雪崩
缓存雪崩，即当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB) 带来很大压力。通常有三种方式来处理：
- 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程 查询数据和写缓存，其他线程等待。
- 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。 setRedis（Key，value，time + Math.random() * 10000） 代码
- 做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短 期，A2设置为长期（此点为补充）
缓存击穿
缓存击穿，即缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存 过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。处理方式： 使用redis的setnx互斥锁先进行判断，这样其他线程就处于等待状态，保证不会有大并发操作去操作数据库。
f(redis.sexnx()==1)
{
//先查询缓存
//查询数据库
//加入缓存
}
缓存穿透
缓存穿透，即对不存在的key进行高并发访问，导致数据库压力瞬间增大。一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如 DB）。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力。
如何解决呢？
- 在服务器端，接收参数时业务接口中过滤不合法的值，null，负值，和空值进行检测和空值。
- bloom filter：类似于哈希表的一种算法，用所有可能的查询条件生成一个bitmap，在进行数据库 查询之前会使用这个bitmap进行过滤，如果不在其中则直接过滤，从而减轻数据库层面的压力。 采用的是一票否决 只要有一个认为你不存在 就认为你是不存在的
- 空值缓存：一种比较简单的解决办法，在第一次查询完不存在的数据后，将该key与对应的空值也放入 缓存中，只不过设定为较短的失效时间，例如几分钟，这样则可以应对短时间的大量的该key攻击，设置 为较短的失效时间是因为该值可能业务无关，存在意义不大，且该次的查询也未必是攻击者发起，无过久存储的必要，故可以早点失效
缓存降级
缓存降级，即当访问量出现剧增、服务出现问题（相应时间慢或者不响应） 或非核心业务影响到核心流程的性能，还 需要保证服务的可用性，即便有损服务。解决方式：
- 系统根据一些关键数据进行降级
- 配置开关实现人工降级
缓存更新
自定义的缓存淘汰策略：
- 定期去清理过期的缓存
- 当有用户请求过来时，先判断这个请求用到的缓存是否过期，过期的话就去底层系统得到新数据进行缓存更新
多个系统同时操作（并发）Redis带来的数据问题
某个时刻，多个系统实例都去更新某个 key。可以基于 Zookeeper 实现分布式锁。每个系统通过 Zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 Key，别人都不允许读和 写。 要写入缓存的数据，都是从 MySQL 里查出来的，都得写入 MySQL 中，写入 MySQL 中的时候必须保 存一个时间戳，从 MySQL 查出来的时候，时间戳也查出来 每次要写之前，先判断一下当前这个 Value 的时间戳是否比缓存里的 Value 的时间戳要新。如果是的 话，那么可以写，否则，就不能用旧的数据覆盖新的数据。
结束
此次分享的redis常见问题就这么多了，需要交流学习可以关注公众号【温故知新之java】，互相学习，一起进步
