Redis--我不怕你。

在这里插入图片描述
自从上次第一次使用Redis，加上不久前做项目又用到了Redis,现在又刷了好多面试题又。。。遇见了Redis,不禁感叹Redis你是多么神圣的存在啊。这次主要记载下项目中使用Redis以及碰见几个问题和解决方案。

起因：

忙了一阵子终于把商城页面功能给完成的差不多，心中老开心了。这时可怕的人格A说道：“大兵长，如果页面要是被用户高频访问，同时进攻DB，怎么办！”。“从数据库入手是调优性价比最高的切入点，使用缓存进行优化一波吧，缓存可以理解是数据库的一道保护伞，任何请求只要能在缓存中命中，都不会直接访问数据库。而缓存的处理性能是数据库10-100倍。”
解决方案：使用Redis作为缓存系统进行优化。
安装Redis:请参考：https://blog.csdn.net/qq_42534991/article/details/104264377
人格B：“就算使用了Redis,高并发时，（缓存击穿）1如果redis宕机了，或者链接不上，怎么办？（缓存雪崩）2如果redis缓存在高峰期到期失效，在这个时刻请求会向雪崩一样，直接访问数据库如何处理？（缓存穿透）如果用户不停地查询一条不存在的数据，缓存没有，数据库也没有，那么会出现什么情况，如何处理？”

缓存问题

1缓存穿透
简单来说就是查询一条不存在的数据，那么既然不存在，就会去数据库中查找，数据库也不存在，并且处于容错考虑，我们没有将这次查询的null写入缓存。那么会导致这个不存在的数据每次都要到数据库中查询，缓存意义就没得了。特别高并发（大佬们不断针对频繁访问），DB就要死翘翘了。那么一些人会利用这个不存在Key频繁攻击应用，这就是一个很大的漏洞。
解决办法：最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。那么还有一个粗暴简单的，我就是采用这种方法的（通常也是采用这种方式）我们仍然把这个空结果进行缓存，因为空结果进行缓存，它的过期时间会很短，最长不超过五分钟。

2缓存雪崩
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。那么全部转发到DB，此时可能会对数据库和CPU造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。
解决办法：三种常见方法（1）原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件.（2）给每一个缓存数据增加相应的缓存标记记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。（3）一般并发量不是特别多的时候，使用多的解决方案是加锁排队
3缓存击穿
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：如果这个key在大量请求同时进来前正好失效，那么所有对这个key的数据查询都落到db，我们称为缓存击穿。
**解决方案：**在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。（加分布式锁）。
第一种分布式锁是Redis自带的一个分布式锁，set px nx.
在这里插入图片描述第二种利用Redission框架，一个Redis的带有JUC的lock功能的客户端实现(既有jedis的功能，又有juc的锁功能)

虽然缓存问题算是解决了吧。但不耐烦的人格又开始不断反问。。。。。好无奈。那好吧。