开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第7天，点击查看活动详情
redis 常见问题
-
之前我们了解了redis 为什么能够这么受欢迎，同时也分析了为什么mongo似乎不是很火， 今天我们来看看redis会出现哪些极端情况的下问题吧。
-
首先我们提到的就是缓存穿透，然后是缓存击穿，最后就是灾难--缓存雪崩。
一、缓存穿透
- 缓存穿透通常指的就是名存实亡，就是使用了redis但是每次缓存无法命中，导致最终的请求还是落到的数据库上，表现出的就是redis给人感觉不作为。用你和没用是一样的。
- 造成这种情况的就是我们程序员预判不够准确，某些数据明明很收欢迎，但是却没有选择缓存到redis中，这就导致了缓存穿透。
- 解决办法也很好结局，就是我们将我们需要的key对应的数据填充到缓存即可。
- 但是还是会存在一个问题就是，比如我们接口通过用户名访问信息，这个时候我们就是通过用户名进行存储在redis中，但是黑客通过不存在的用户名不断的访问接口，这样就造成我们数据库也不存，自然redis就不存在，redis不存在了那么并发接口自然就到了数据库的压力，针对这种恶意情况我们可以将在没哟数据的情况下，将key存储到redis中同时存储一个空值，这样就可以利用redis阻挡部分压力了。
二、缓存击穿
-
缓存击穿呢就是说当请求进来的时候redis中的确存储过，但是已经过期了。在过期--重新生成这个阶段恰巧有了大量的请求，暗那么这个阶段压力还是需要数据库自己抗的。 解决方法
-
那上述的场景该如何解决呢？我们可以让并发的请求串行化，就是接口首先是访问redis的，发现没有此时只需要1个线程去访问数据库同时像redis中生成缓存数据，其他线程就原地等待redis中有数据之后在重新访问redis，这样就能够拿到数据了。
-
还有一种解决方案就是设置key永远不过期
三、缓存雪崩
-
指在系统运行过程中，缓存服务宕机或大量的key值同时过期，导致所有请求都直接访问数据库导致数据库压力增大。
-
想要解决缓存雪崩就不好做了，或者说解决之后无法有效进行验证了，因为我们需要打乱key的分布，以及过期时间也让他随机分布。
