上期文章我们聊了一下Redis的主从复制、持久化以及哨兵机制，相信大家一定收获满满，这些可是进入大厂的必备板砖啊，这期我们接着放大招，来聊聊Redis的雪崩、击穿和穿透，哈哈哈……
作为合格的搬砖人员，我们知道一般都会把热点数据，尤其像某宝某东什么什么啦等首页数据，提前缓存下来，这样用户打开首页时加载的速度就会快很多，体验会好一点，而且对系统存储层的MySQL也是安全的。然后用定时任务去定时刷新数据。
只有当缓存系统失效获取不到数据时，才会降级直接到MySQL请求数据。
像我之前做过的一个产品的首页推荐数据就是这样设计的，提前定时将数据缓存在Redis中的，这样首页的打开速度就会很快了。
不过这都是理想状况，现实却总是那么骨感，打的你猝不及防。
雪崩
比如这样一个场景：当缓存服务器突然重启，或者大量缓存数据的Key的失效时间都集中在某一时间点，而这个时候，比如说公司这个时候正在做一个秒杀活动，本来缓存系统设计能抗住10w的QPS，这时候由于缓存层失效了，只能直接去请求MySQL，你想想，10W+的QPS直接到MySQL层，那MySQL一定会挂掉的。
这就是业界著名的雪崩，要知道雪崩的时候没有一片雪花是无辜的。
那该怎么办呢？有以下几种解决方案：
方案一：使用我们上篇聊到的Redis集群高可用方案，即sentinel部署方案，如果某个机器挂掉，可以随时由其它的机器顶上来；
方案二：不同的Key设置不同的过期时间，从而保证数据不会集中某一个时间点失效；
方案三：设置缓存永久不过期；
方案四：使用互斥锁，不过这个方案实现比较复杂，就是在缓存失效的时候，通过加锁或者队列来控制请求的数量，单机可以使用synchronized或者lock。分布式环境可以使用setnx命令；
方案五：使用Netflix Hystrix断路器，这是微服务架构中提供服务隔离、熔断、降级机制的工具，用于微服务高可用，是防止服务出现雪崩的利器。
击穿
击穿从这个词上就可以摸索出一些味道了。
何为击穿？可以想象一下，拿笔去刺一张纸，他会把纸穿一个窟窿。
同理，Redis击穿就是指大量的请求集中的对某一个点不停的去请求，当这个Key在失效的那一瞬间，大量的请求就会直接击穿缓存层，直达MySQL。这么大的请求，MySQL肯定扛不住的，直接就挂掉了。
这肯定不是你想看到的状况，对吧！哈哈哈……
那该如何解决呢？
很简单，可以直接采用雪崩解决方案三和方案四，就是直接设置Key永不过期和加互斥锁。
穿透
穿透和击穿看起来好像没啥区别，但还是有区别的，从字面上来看，穿透明显温柔了许多，但还是太过暴力了，哈哈哈……
我们知道Redis是Key-Value系统，所以是按照key去找对应的value，找不到的时候就会直接从MySQL层查询，如果大量的请求到来，就会导致数据库压力过大，从而压垮数据库。
看起来好像和击穿好像没啥区别哈……不过你细品。
那该如何解决呢？
方案一：就是不让这种情况发生。一般老油条搬砖工都会对用户请求的数据做参数校验的，因为我们坚信用户是不可靠的，但是就怕菜鸟忘记了参数校验，这就完蛋了，所以，一定要记得参数校验，没用的参数一定要及时清空或置为null，养成好习惯。
方案二：就是采用大名鼎鼎的布隆过滤器。为什么说它是大名鼎鼎呢，我这里就卖个关子，你以后就知道了，哈哈哈……
关于布隆过滤器，后面我会专门出一篇文章详细介绍一下它及应用场景，想看的记得关注我啊。
总结
这就是Redis中著名的雪崩、击穿和穿透了，只要你想在大厂搬砖，一定会用到或进门的时候被问到的。
虽然这些问题看起来好像很简单，但是放在生产环境，几十上百台机器如果发生这种情况，那就是项目事故了，对公司的影响可能是致命的，所以，一定要熟练的掌握。
OK，这期文章可真是精华，也是进入大厂的必备板砖之一，写到最后，我都不忍心发出来了，哈哈哈……
不过咱是又渣又成熟的大叔，当然是要让大家白嫖的嘛！
如果你觉得大叔写得还不错，
求关注、求点赞、求分享
，毕竟大叔熬肝码字也是很幸苦的嘛，当然，如果你是个妹子，也欢迎直接小窗找我哦！
我是诗远君，一个流浪在互联网江湖的大叔。
我们下期见！
288
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
