Redis常见问题及解决方案

Coding的哔哔叨叨 2021-01-25

233

本是没计划写这个方面的内容的，感觉也就那么几个点，翻来覆去的说，不过最近有朋友反映，网上的各种文章写得有点深奥，哈哈哈哈，那我就用大白话来说下各种问题，下面开始今天的内容。

缓存穿透

Coding的哔哔叨叨

这个问题，在上篇文章Redis布隆过滤器中提及过，这里我们详细解释下。

缓存穿透，就是说，请求一个数据库和缓存中都不存在的数据，这就造成每次请求都落在数据库上，我们称此现象为缓存穿透。

设想下，假如有人借用缓存穿透来攻击我们的服务，伪造大量不存在或用一个不存在的id，大量频繁的访问我们服务，引起数据库服务压力倍增甚至宕机。

穿透问题怎么解决呢？在这说两种方式，具体使用哪种方式，大家根据自己的业务场景去自行选择。

我们可以将请求不存在的数据默认值或者空值放到redis中，这样同样的请求第二次请求的时候就不会再落在数据库上了。

但是，这种方式一定要注意，如果之后数据库中数据新增后，如果有空值被缓存，记得要更新缓存，这种缓存不一致的问题一定要多注意，最好是缓存空值时，设置一个key过期时间。

在上篇redis布隆过滤器的文章中，我详细的聊过了，所以这里就不再详细解释了，redis布隆过滤器可以过滤掉绝大一部分不存在的key值，但不是绝对，所以这也是大家需要防范的一个点。

缓存击穿

Coding的哔哔叨叨

击穿的问题，大家很容易和上面的穿透混淆，击穿是说：某一个redis中key，有大量请求在访问，某个时刻，这个key失效过期了，这时候有大量请求都落在了数据库上，这时候导致数据库压力剧增，甚至引发宕机。

看明白了击穿的场景，我们也就基本想到了解决击穿的思路，对的，用分布式锁，当redis中的key过期后，我们让所有的请求都去竞争同一把锁，其他请求线程等待，等缓存好后，从缓存中继续提供数据。

缓存雪崩

Coding的哔哔叨叨

雪崩的场景有两种，一种是某一时刻redis的key大面积过期（key的失效时间过度集中），另一种是由于redis服务宕机直接引发的所有key都是失效，这时候，所有的请求进来都落在了数据库上，数据库不堪重压而引起宕机。

针对上面的两种场景，我们分别来解决：

场景一是由于大量key失效时间过于集中而引发雪崩，这时候，我们可以在key的过期时间上做文章，在定义的过期时间上加上或减去一个时间范围内随机的时间，让key的失效时间错开，这样便可以有效避免雪崩。
场景二我们分三步来解决：

对redis服务采用集群或哨兵+主从来实现高可用，来避免整个redis服务全部不可用。

采用本地缓存如ehcache和服务限流&降级，避免数据库在短时间内被突然打死，用本地缓存来提供缓存服务，还是可以撑一阵子的。

redis开始持久化机制，待redis服务恢复后，可以自动恢复磁盘上的数据。

以上就是今天所有的内容，实际中redis还有很多其他的问题，大伙有啥疑惑可以评论区留言。

不积跬步，无以至千里。

文章有帮助的话，点个转发、在看呗。
谢谢支持哟 (*^__^*)

END

👇

文章转载自Coding的哔哔叨叨，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。