redis 常见面试内容，缓存穿透、缓存雪崩 、缓存击穿
一、缓存穿透：
本质：
查询缓存中没有的数据，流量直接到了mysql
造成这种现象的情况分多种 ，可以是黑客攻击，笔者遇到过有人利用技术手段获取系统中注册手机号信息。
可以是系统调用出错。
也可以是数据逻辑错误。
举个例子：
对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。
黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。
举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。
解决方案：
空值设置缓存
解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。这样的话，下次便能走缓存了。
1，当查询不存在时，也将结果保存在缓存中。但是这可能会存在一种问题：大量没有查询结果的请求保存在缓存中，这时我们就可以将这些请求的key设置得更短一些。
提前过滤请求
使用布隆过滤器，把redis 已经缓存的数据写入过滤器，但这个适合特定类型缓存，假如一场线上促销结束了呢；
使用时需要注意，redis 的Bloom Filter 不能删除数据。
2，提前过滤掉不合法的请求，Redis实现了布隆过滤器，我们可以使用它来达到这个目的。布隆过滤器很好理解，可以参考布隆过滤器(Bloom Filter)的原理和实现。
校验缓存的key值
- 对于key设置一定的规范，进行校验，对于不符合规范的key 直接返回 假数据或者异常数据
最好对于每一个缓存key都有一定的规范约束，这样在程序中对不符合parttern的key 的请求可以拒绝。（但一般key都是通过程序自动生成的）
合法的请求与布隆过滤器的过滤的请求的关系，合法的请求在布隆过滤器中一定可以经过，但是布隆过滤器并不能完全拦截所有非法的请求。应用在缓存上，我们能够拦截绝大部分请求即可。
缓存预热
缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在⽤户
请求的时候， 先查询数据库，然后再将数据缓存的问题!⽤户直接查询事先被预热的缓存数
据!
二、缓存雪崩：
2.1缓存雪崩的原因：
1.在高并发下，大量的缓存key在同一时间失效，导致大量的请求落到数据库上，如活动系统里面同时进行着非常多的活动，但是在某个时间点所有的活动缓存全部过期。
2.redis 单点 redis故障
3.redis 未配置持久化
缓存雪崩 特点是一时间 缓存失效或者消失，大量请求落到Mysql上
所以 对于并发量低的系统 不太可能出现缓存雪崩
2.2 解决方案：
解决缓存雪崩我们也有两种解决方案：
1，在设置Redis键的过期时间时，加上一个随机数，这样可以避免。
2，部署分布式的Redis服务，当一个Redis服务器挂掉了之后，进行故障转移。
redis 哨兵模式，持久化配置。
3. 系统本地ehcache 缓存 限流 降级 避免mysql 打死 一级缓存 二级缓存
4.缓存失效之后 设置锁 用加分布式锁或者分布式队列的方式保证缓存的单线程（进程）写 （eg. redis的 SETNX），从而避免失效时大量的并发请求落到底层存储系统上。在加锁方法内先从缓存中再获取一次(防止另外的线程优先获取锁已经写入了缓存)，没有再查DB写入缓存。 （当然也可以： 在没有获取锁(tryLock)的线程中一直轮询缓存，至超限时）
缓存雪崩的redis 可靠性解决方案如下。
事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。
事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 redis。如果 ehcache 和 redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 redis 中。
限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降级！可以返回一些默认的值，或者友情提示，或者空白的值。
好处：
数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次。
三、缓存击穿：
缓存过期之后 一秒 大量请求达到
需要内部 缓存，排队，
缓存击穿又是一个听起来很晦涩的概念。它指的是在缓存过期的后一秒，有大量的请求并发的请求过期的键，这是因为缓存已经过期了，所有的请求都发送到数据库中了。
解决缓存击穿的方法与解决缓存穿透的方法一样。
四、缓存抖动
cache thrash
缓存抖动是由于正在进行的计算无法读取缓存系统数据导致失败的现象。
缓存一致性是指在多处理器系统中，多个缓存可以共享一个数据拷贝，当其中一个缓存的值改变时，它必须和其他缓存通信，从而告知这一改变，并更新数据保证所有拷贝为同一值。
处理器相关性是指，跟踪进程最后一次执行所使用的处理器，并尽可能在下一次执行时使用相同的处理器。这样可以尽量使进程使用同一缓存，从而获取高性能，因为缓存失效会使处理器空转几十个时钟周期。
缓存抖动描述的是 CPU 读取内部缓存系统的时的问题。
在更换页面时，如果更换页面是一个很快会被再次访问的页面，则再次缺页中断后又很快会发生新的缺页中断。
整个系统的效率急剧下降------这种现象称为颠簸（抖动）
内存颠簸的解决策略是：
-
1-如果是因为页面替换策略失误，可以修改替换算法来解决这个问题；
-
2-如果是因为运行的程序太多，造成程序无法同时将所有频繁访问的页面调入内存，则要降低多道程序的数量。
-
3-否则，还剩下两个办法：1终止该进程；2增加物理内存容量；
Contributor(s): Cameron McKenzie
Cache thrash is caused by an ongoing computer activity that fails to progress due to excessive use of resources or conflicts in the caching system. A key sign of cache thrashing is high CPU usage or a system that seems to be running very slowly. In thrashing, the computer will typically take the same actions over and over in an attempt to complete the desired task. One process diverts resources from another process, which in turn must take resources from another process in a vicious cycle if the total resources available are insufficient. For example, a translation lookaside buffer (TLB) may have to be completely reloaded to capture data on each sweep if the CPU cannot address the total number of pages involved. This means there is no TLB cache reuse, leading to inefficiency and long load times. In this case, thrashing can be occurring even if there are no page faults.
Cache thrash can sometimes be related to context switching (the procedure to change from one task to another to enable multi-tasking while avoiding any conflict). The underlying cause may be that thread pools are not sized properly in servlet containers or the algorithms used may be a poor match for the type of data being accessed. Methods such as cache coherency protocols that permit multiple caches to share a memory copy of a data item may limit thrashing in some use cases.
参考：https://searchsoftwarequality.techtarget.com/definition/cache-thrash