在应用redis缓存时，咱们大略都听过缓存击穿、缓存雪崩之类的场景和计划，这也是个别常见面试题的内容。但在这些年的理论开发中，确实亲身经历了这类场景之后，对这类场景和解决方案就更加粗浅，这类再对立总结一下。
当然计划不是惟一的，后续如果我用到更好的计划，仍然会基于本文档补充。
1. 缓存击穿
1.1. 定义
缓存击穿，也就是说当redis缓存中有一个key是大量申请同时拜访的热点数据，如果忽然这个key工夫到了，那么大量的申请在缓存中获取不到该key，穿过缓存间接来到数据库导致数据库解体，这样因为单个key生效而穿过缓存到数据库称为缓存击穿。
1.2. 计划
1.2.1. 计划一：被动更新key
这里问题在于key是被动刷新的，即key过期后主动删除，当流量申请进来了才去读db更新缓存。如果场景容许，咱们能够被动控制性的刷新key。key仍然能够设置过期工夫，但咱们能够通过后盾job等形式，从db拿最新的值更新key对应的value，更新的同时天然对key进行续期。
这样以达到能定时更新redis值，又保障redis key永远不生效，突发大流量也走不到db。
1.2.2. 计划二：更新缓存加锁
缓存击穿的场景在压测中常常可见，当没有缓存预热时，redis 缓存key一开始不存在。假如jmeter 100个线程并发拜访时，都发现缓存key不存在，100个申请都会去查问db，而后更新redis值。
其实咱们在发现key不存在之后，能够对于“查db更新redis缓存”这个过程加上分布式锁，保障只有有一个申请去读db、更新缓存。其余的申请在期待锁开释后，再去查下redis缓存。此时缓存有值就间接拜访缓存。
2. 缓存雪崩
2.1. 定义
当大量申请在拜访都会先从缓存查问，如果此时大部分缓存同时过期生效，那么这些申请都查问不到缓存，此时他们会全副将申请到数据库，当申请数量足够大时此时将会把数据库压垮，这就是缓存雪崩。比方：在凌晨十二点搞促销，大概有10000个用户发动申请，此时缓存过期，则这10000个申请间接打到数据库上，把数据库压垮，即便重启数据库申请仍然会打到数据库上。
这里和“缓存击穿”不同的中央在于：
- 缓存击穿：单个key过期，单个key的大量申请进来。
- 缓存雪崩：多个key同时过期，多个key的大量申请进来。
2.2. 计划
2.2.1. 计划一：过期工夫扩散
问题在于key同时过期。首先，如果业务上key的生成工夫不是同时的，那么过期工夫也就不是同时的，这类问题能够防止。
如果key的生成工夫是同时的，例如：缓存是通过job或其余触发条件批量一起生成的，那么在定义每个key的过期工夫时，能够基于原定的工夫再加上一个随机时间段，以保障最终的过期工夫不统一。
2.2.2. 计划二：集群架构
redis的集群架构中，可依据写入命令依照不同slot，调配在不同master上。因为这些key是不同的，针对缓存雪崩场景，写入的申请就能够调配在不同master节点上，能缓解一部分压力。
当然，成果无限，但至多比单体架构抗压强。
2.2.3. 计划三：降级限流
可评估数据库能承受的最大申请量，做限流。那么被限住的申请就要做服务降级，可在队列中期待异步更新redis值。
3. 缓存穿透
3.1. 定义
指当申请查问缓存和数据库都不存在的数据时，先查问缓存为空，再查询数据库仍然为空，向申请返回空，如果大量申请同时拜访这些不存在key那么这些申请仍然会造成压垮数据库的景象，这种通常是歹意查问和被攻打几率较大。
缓存穿透 和 缓存击穿 名字听起来很像，但不是一回事。缓存穿透 是针对缓存中不存在的key。而 缓存击穿 是本来存在某个缓存key，等生效后忽然大批量拜访这个key。
3.2. 计划
3.2.1. 缓存null值
当拜访一些不存在的key时，因为在db中查到的值为null，就不会缓存下来，所以下次访问仍然会走db。
那么当在db中查到的值为null时，咱们罗唆就创立一个缓存key，存的值就为null等。当下次访问的时候，就会走缓存中取，而不必走db。
然而这个计划有局限性，得看具体场景。假如第一次拜访的时候不存在，咱们缓存了一个null的key，很快db中对应的key就有值了，可咱们拜访时仍然是从缓存中获取了null。
有两种改良策略：
- 能够针对null的值，咱们的过期工夫能够设短一点。（上策）
- 当db中值新建、更新时，可能被动革除对应的缓存key。（上策）
3.2.2. 布隆过滤器
详见 《布隆过滤器 与 Redis BitMap》
4. 热点key（缓存击穿）
4.1. 定义
这里 （缓存击穿），是因为和缓存击穿场景有点像。后面说的缓存击穿，单指key过期，大流量击穿db。而这里不必等到key过期，间接更大的流量，击穿redis，再击穿db。
热点key，就是霎时有大量的申请去拜访redis上某个固定的key。例如一些热搜词条：IG夺冠、梅西夺冠，一瞬间会有大量的用户申请都拜访固定的词条，如果这些词条内容存在redis中，那么拜访的就是某个固定的key。
咱们晓得，就算是redis的集群机构，针对某个固定的key，也是被调配某个固定的哈希槽上，对应redis某单个节点。而redis单个节点的性能无限，此时就容易被击溃，带来的危害有：
1. 流量集中，达到物理网卡下限
当某一热点Key的申请在某一节点所在的主机上超过该主机网卡流量下限时，因为流量的适度集中，会导致该节点的服务器中其它服务无奈进行
2. 申请过多，缓存分片服务被打垮
Redis单点查问性能是无限的，单节点QPS差不多也就几万，当热点key的查问超过Redis节点的性能阈值时，申请会占用大量的CPU资源，影响其余申请并导致整体性能升高；重大时会导致缓存分片服务被打垮，表现形式之一就是Redis节点自重启，此时该节点存储的所有key的查问都是不可用状态，会把影响辐射到其余业务上。
3. 集群架构下，产生拜访歪斜
即某个数据分片被大量拜访，而其余数据分片处于闲暇状态，可能引起该数据分片的连接数被耗尽，新的连贯建设申请被回绝等问题。
4. DB 击穿，引起业务雪崩
热Key的申请压力数量超出Redis的承受能力易造成缓存击穿，当缓存挂掉时，此时再有申请产生，可能间接把大量申请间接打到DB层上，因为DB层绝对缓存层查问性能更弱，在面临大申请时很容易产生DB雪崩景象，重大影响业务。
4.2. 辨认热点key
4.2.1. 业务教训评估
比方热搜关键词、秒杀商品的词条等等，可能提前辨认到可能是热点key的，就提前做筹备。
4.2.2. 业务侧监控
在操作redis之前，退出一行代码进行数据统计，异步上报行为；如相似日志采集，将单次redis命令的操作/后果/耗时等统计，异步音讯发送给采集音讯队列，毛病就是对代码造成入侵，个别能够交给中间件加在本人包的redis二方包中；如果有做的好一点的Daas平台，能够在proxy层做监控，业务无需感知，对立在Daas平台查看redis监控。
4.2.3. redis服务器端监控
redis自带一些监控命令，可由运维侧基于redis的命令，提供一些监控平台。
1. monitor命令
该命令能够实时抓取出redis服务器接管到的命令，而后写代码统计出热key是啥；当然，也有现成的剖析工具能够给你应用，比方redis-faina；然而该命令在高并发的条件下，有内存增暴增的隐患，还会升高redis的性能。
2. hotkeys参数
redis 4.0.3提供了redis-cli的热点key发现性能，执行redis-cli时加上–hotkeys选项即可；然而该参数在执行的时候，如果key比拟多，执行起来比较慢。
4.3. 计划
4.3.1. 二级缓存
针对热点key做二级缓存，将流量摊派到java各个节点的内存中，也缩小了网络带宽。
当然，二级缓存带来的毛病就是难保护缓存的一致性。不过这也算是针对热点key场景下的一种降级策略。
4.3.2. key正本拆分
能够将某个key的内容复制成多个key，如：xxkey_01、xxkey_02、xxkey_03...，这样这些key就会扩散在不同的哈希槽中，不同的redis节点上。
在java代码每次申请redis key时，能够通过轮询等形式，拜访不同key中的数据。就将流量平摊到不同的redis节点中。
后面是设置编号，拜访时随机拜访其中一个key。还能够思考依照用户群体、拜访场景等维度拆分，拆分生成不同的key，同样的思路，也是能够将流量拆离开。
4.3.3. 热点key redis集群隔离
如果财力容许，为了避免热点key引发问题时，外围业务不受影响，该当提前做好外围/非核心业务的Redis的隔离，至多热点key存在的redis集群该当与外围业务隔离开来。
4.4. 有赞TMC框架履行
有赞专门设计了一套框架解决热点key的问题，具体内容请看原文 《有赞通明多级缓存解决方案（TMC）设计思路》。上面做简略阐明。
TMC 本地缓存整体构造分为如下模块：
- Jedis-Client：Java 利用与缓存服务端交互的间接入口，接口定义与原生 Jedis-Client 无异；
- Hermes-SDK：自研“热点发现+本地缓存”性能的 SDK 封装，Jedis-Client 通过与它交互来集成相应能力；
- Hermes 服务端集群：接管 Hermes-SDK 上报的缓存拜访数据，进行热点探测，将热点 key 推送给 Hermes-SDK 做本地缓存；
- 缓存集群：由代理层和存储层组成，为利用客户端提供对立的分布式缓存服务入口；
- 根底组件：etcd 集群、Apollo 配置核心，为 TMC 提供“集群推送”和“对立配置”能力；
1. 监控
有赞改写了jedis原生的jar包，退出了Hermes-SDK包，目标就是做热点发现和本地缓存；
从监控的角度看，该包对于Jedis-Client的每次key值拜访申请，Hermes-SDK 都会通过其通信模块将key拜访事件异步上报给Hermes服务端集群，以便其依据上报数据进行“热点探测”。
2. 热key解决计划
在解决热key计划上，有赞用的是二级缓存。
有赞在监控到热key后，Hermes服务端集群会通过各种伎俩告诉各业务零碎里的Hermes-SDK，通知他们这个key是热key，要做本地缓存。 于是Hermes-SDK就会将该key缓存在本地，对于前面的申请；Hermes-SDK发现这个是一个热key，间接从本地中拿，而不会去拜访集群；
3. 二级缓存一致性计划
Hermes-SDK的热点模块仅缓存热点key数据，绝大多数非热点key数据由缓存集群存储；
热点key变更导致value生效时，Hermes-SDK 通过etcd集群播送事件，异步生效业务利用集群中其余节点的本地缓存，保障集群最终统一。