Redis机构设计缺陷

Redis架构设计缺陷主要分为两方面

1.缓存穿透

2.缓存击穿

缓存穿透是什么？

所谓的缓存穿透，简单来讲就是查询某些不存在的key时，缓存和数据库查询结果都为空，而空的结果又不被缓存起来，而导致每次查询都去请求数据库层的情况。

过程：

缓存不命中，进而导致每次查询都去查询数据库，缓存也就失去了作用，通常表现为服务器负载迅速上升，严重时可能直接宕机。

常见场景

日常网站开发中，我们通常会将一些访问频繁的页面缓存起来，比如文章详情页、商品详情页等，而这些又恰恰是爬虫最喜欢访问的页面，如果缓存设计不合理，遇到不负责任的爬虫，顺着ID频繁抓取数据，后果是非常严重的！

另外，有很多同学写代码时不够细心，特别是循环去调用某些接口时容易出现缓存的情况，有时候威力堪比恶意攻击（泪奔）。

预防措施

常见的两种方法是缓存空数据和使用布隆过滤器，需要根据实际场景进行选择。

1.缓存空数据

当第一次查询数据库时，若数据不存在，返回空数据时将其写入缓存，后续查询就不必再去查询数据库了。

存在问题：

如果key过期时间较长，出现恶意攻击时，容易出现内存不够的情况。另外，需要额外的业务逻辑处理数据库与缓存中数据一致性的问题。

2.布隆过滤器拦截

访问缓存之前，先从布隆过滤器中验证数据是否存在。

简单来讲就是使用多个hash函数将一个key映射到一个很长的二进制向量的多个比特位中，类似于hash set。

存在问题：维护复杂，建议只在海量数据的情况下使用。

缓存击穿是什么？

所谓的缓存击穿，就是我们对于热点数据设置缓存时，对于这些key的过期策略考虑欠缺，而导致某个热点key过期时大量的请求瞬间穿透到数据库层，造成DB负载飙升，甚至服务器宕机的情况。

这里针对的主要是单个key的情况，对于批量key过期策略不当造成的问题通常被称之为缓存雪崩。它们二者之间十分相似却又有所不同，这里我们主要说说击穿的情况，有兴趣的可以再去深入了解。

过程：

原先热点key中的数据不需要去查询DB，流程是这样的：

某个key过期时候，如果处理不当，就变为以下这样：

如果过期瞬间的并发量很大，那么问题就出现了。

常见场景

商城经常会有抢购、秒杀一类的活动，参加活动的商品数据会被缓存起来，又比如运营人员发表的某篇文章、某张图片，这些都有可能成为热点数据，也都会被缓存起来。

解决方案

1.多个热点key的缓存过期时间应该被均匀错开；

2.重新设计缓冲过期方式，让其永远不会自动过期，这里的不过期并非真的不过期，而是配合使用分布式锁，当数据缓存超过一定时间之后，只有取得锁的请求允许重建缓存，其余均返回旧数据。

ps：关于如何使用Redis实现分布式锁，之前我们已经介绍过，还不清楚的小伙伴记得等会翻回去看看。

其他问题

除了上面缓存过期的问题，在超高并发的环境中，可能还会遇到以下的问题

1.单个value的大小造成的网络阻塞；

2.如何避免因出现单机热点，比如热点key都落到同一台机子上面；