目录

一、Redis缓存

二、Redis使用缓存遇到的问题

2.1 数据一致性

2.2缓存雪崩

2.3 缓存穿透

2.4 缓存击穿

一、Redis缓存

数据缓存是Redis最重要的一个场景，为缓存而生，在springboot中，一般有两种使用方式：

• 直接通过RedisTemplate使用

• 通过Spring Cache集成Redis(也就是注解的方式)

二、Redis使用缓存遇到的问题

2.1 数据一致性

在分布式环境下，缓存和数据库很容易出现数据一致性问题，如果项目对缓存的要求是强一致性，那就不要使用缓存。

我们只能在项目中使用策略降低缓存与数据库一致性的概率，是无法保障两者的强一致性，一般策略包括缓存更新机制，更新数据库后及时更新缓存、缓存失败时增加重试机制

2.2缓存雪崩

在了解雪崩溃之前，我们先了解什么是缓存雪崩现象，假设A系统每秒需要处理5000个请求，但数据库每秒只能处理4000个请求，某一天，缓存机器出现了宕机，挂了，这时候所有的请求一下子全部落在数据库上，数据库肯定扛不住，报警挂掉了，这时候如果没有采取缓存设施，数据库又急着用，重新重启数据库，刚重启完成(有可能没启动完)，请求又来，数据库立马挂掉。这就是雪崩事件，是Redis缓存中最致命问题之一(有一个是穿透)。大家可以看看下图

出现雪崩事件后不要急不要慌，我们可以在事故前中后三个方面来思考解决方案

• 事故前：redis高可用方案，主从+哨兵，集群方案，避免全盘崩溃

• 事故中：较少数据库的压力，本地Ehcache缓存+限流及降级，避免超过数据库承受压力

• 事故后：做redis持久化，一旦Redis重启，可从磁盘中快速恢复数据

我们来看看改造后的数据流程，假设用户A发送一个请求，系统先请求本地Ehcache是否有数据，如果没有再去Redis请求数据，如果没有再去数据库请求数据，获取到数据后同步到Ehcache和redis

限流组件的作用：可以设置每秒请求数次，有多少通过请求，剩余的未通过的可以走降级处理，返回一些默认的值，或者友情提示等默认操作。具体流程可以看看下图：

这样做的好处是:

• 数据库安全：在限流组件可用的情况下，数据库不会挂掉，限流根据确保了每秒多少请求能通过。

• 部分请求可以被处理：数据库没挂，就意味着至少2/5的请求可以被处理掉

• 高峰时期部分请求无法处理到，需要用户多次点击，因为只有2/5的请求被处理，剩下的请求，用户刷不出来界面，需要多点击几次

• redis设置的缓存失效时间不是设置成同一个时间，可根据功能、业务、请求接口灵活设置缓存时间：setRedis（key, value, time+Math.random()*10000）;

2.3 缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，用户(黑客)不断发起请求，导致请求直接查询数据库，这种恶意行为攻击场景的会直接导致数据库挂掉，数据流程如下图所示

image

处理这种情况相对比较简单点，这种情况是绕过redis或本地缓存直接到达数据库，可以采取以下方案：

• 在请求接口层可以做一些校验，比如用户签权、参数校验，不合法的请求直接return，

• 还可以针对有效id做认证或直接拦截，不符合的id直接过滤或采用统一key保存到redis，下次不合法的id请求时，直接到缓存中获取数据

• 采用redis的高级接口Bloom Filter，利用高效的数据结构和算法快速判断出你这个 Key 是否在数据库中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return

2.4 缓存击穿

上面讲的穿透是针对大面积数据请求，那么击穿是针对一点(一个key)来导致redis异常，但某个key是非常热点，请求非常频繁，处于集中式访问现象，当这个key失效(过期)时，大量的请求就会击穿了缓存，直接请求数据库，就像在屏障中凿开了一个洞。

不同场景下缓存击穿解决方案

• 数据基本不变：热点数据value基本不更新时，可以设置成永不过期

• 数据更新不频繁：缓存刷新流程耗时较少时，可采用redis、zookeeper等分布式中间件的分布式互斥锁或者本地互斥锁保证少量的请求能请求到数据库并重新更新缓存，其他的流程等锁释放后才可以访问新缓存

• 数据更新频繁：采用定时线程，在缓存过期前主动重新构建缓存或延长过期时间，保证所有的请求能一直访问缓存