新产品+新战略赋能企业数字化转型

哎，最近阿粉又双叒叕犯事了。

事情是这样的，前一段时间阿粉公司生产交易偶发报错，一番排查下来最终原因是因为 Redis 命令执行超时。

可是令人不解的是，生产交易仅仅使用 Redis set 这个简单命令，这个命令讲道理是不可能会执行这么慢。

那到底是什么导致这个问题那?

为了找出这个问题，我们查看分析了一下 Redis 最近的慢日志，最终发现耗时比较多命令为 keys XX*

看到这个命令操作的键的前缀，阿粉才发现这是自己负责的应用。可是阿粉排查一下，虽然自己的代码并没有主动去使用 keys命令，但是底层使用框架却在间接使用，于是就有了今天这个问题。

问题原因

阿粉负责的应用是一个管理后台应用，权限管理使用 Shiro 框架，由于存在多个节点，需要使用分布式 Session，于是这里使用 Redis 存储 Session 信息。

由于 Shiro 并没有直接提供 Redis 存储 Session 组件，阿粉不得不使用 Github 一个开源组件 shiro-redis。

由于 Shiro 框架需要定期验证 Session 是否有效，于是 Shiro 底层将会调用 SessionDAO#getActiveSessions 获取所有的 Session 信息。

而 shiro-redis 正好继承 SessionDAO 这个接口，底层使用用keys 命令查找 Redis 所有存储的 Session key。

 

造成缓存雪崩的主要原因就是缓存集中失效，或者缓存服务发生故障，瞬间的大并发流量压垮了数据库。

如何解决缓存雪崩问题?

解决缓存雪崩问题最常用的一种方案就是保证Redis的高可用，将Redis缓存部署成高可用集群(必要时候做成异地多活)，可以有效的防止缓存雪崩问题的发生。

为了缓解大并发流量，我们也可以使用限流降级的方式防止缓存雪崩。例如，在缓存失效后，通过加锁或者使用队列来控制读数据库写缓存的线程数量。具体点就是设置某些Key只允许一个线程查询数据和写缓存，其他线程等待。则能够有效的缓解大并发流量对数据库带来的巨大冲击。

另外，我们也可以通过数据预热的方式将可能大量访问的数据加载到缓存，在即将发生大并发访问的时候，提前手动触发加载不同的数据到缓存中，并为数据设置不同的过期时间，让缓存失效的时间点尽量均匀，不至于在同一时刻全部失效。

 

造成缓存击穿的主要原因就是：我们为缓存中的数据设置了过期时间。如果在某个时刻从数据库获取了大量的数据，并设置了相同的过期时间，这些缓存的数据就会在同一时刻失效，造成缓存击穿问题。

如何解决缓存击穿问题?

对于比较热点的数据，我们可以在缓存中设置这些数据永不过期;也可以在访问数据的时候，在缓存中更新这些数据的过期时间;如果是批量入库的缓存项，我们可以为这些缓存项分配比较合理的过期时间，避免同一时刻失效。

还有一种解决方案就是：使用分布式锁，保证对于每个Key同时只有一个线程去查询后端的服务，某个线程在查询后端服务的同时，其他线程没有获得分布式锁的权限，需要进行等待。不过在高并发场景下，这种解决方案对于分布式锁的访问压力比较大。

缓存雪崩

如果缓存系统出现故障，所有的并发流量就会直接到达数据库。

什么是缓存雪崩?

如果在某一时刻缓存集中失效，或者缓存系统出现故障，所有的并发流量就会直接到达数据库。数据存储层的调用量就会暴增，用不了多长时间，数据库就会被大流量压垮，这种级联式的服务故障，就叫作缓存雪崩。

我们可以用下图来表示缓存雪崩的现象。

（编辑：怀化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!