redis篇

1.redis雪崩，穿透，击穿

• 缓存雪崩：假设每天高峰请求量每秒1000个请求，本来缓存能够承受每秒800个请求，但是缓存出现了宕机，缓存挂掉了，此时每秒1000个请求全部落在数据库上，它肯定扛不住，他会报一下警，然后挂掉，如果没有采用什么特别的方案处理这个故障，DBA（数据管理员）很着急，重启数据库，但是数据库立马又被新的流量打死，这就是雪崩

总结：短时间内大量的请求，超出缓存能够承受的范围，缓存宕机，大量请求直接访问数据库，造成数据库挂掉，就是雪崩

缓存雪崩的事前事中事后的解决方案如下。

• 事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。（知识点，本人还未用过）
• 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。（知识点，本人还未用过）
• 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。（知识点，本人还未用过）

 

• 缓存穿透：假设短时间内有2000个请求，但是其中却又1800个都是恶意请求，无用的请求，那么对于这1800个请求，缓存中并查不到，这个时候就要取数据库查询，但是在数据库查询也是查询不到，这样的话，缓存对于它来说视为摆设，无用，但是这些短时间内大量的请求会打死数据库，这就是穿透。

总结：短时间内大量的请求，但请求内容在缓存中没有，这些大量请求就会直接到数据库查询，导致数据库死机，就是穿透

解决方案：

• 只要在数据库没有查到，这个时候就在缓存中存入一个空值，设置一个过期时间，这样的话，下次再有相同的key来请求，在缓存失效之前都会访问缓存取数据

 

• 缓存击穿：就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。

解决方式：

• 可以将热点数据设置为永远不过期；或者基于 redis or zookeeper 实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其它请求才能通过该 key 访问数据。

 

redis分布式锁：---（待更新）