当前位置：首页 > news >正文

【Redis】线上并发三大灾难

news 2026/5/31 20:19:11

其实很好理解，一般正常的逻辑是：前端发起查询，先查redis，redis命中就返回数据，如果没有就去查mysql，查到后写入redis里并返回。

现在假设有一个黑客想要搞垮这个网站。

它一直发送请求查询一个不存在的商品ID或者其它东西，他们既不存在于redis中，也不存在于mysql中。

这就造成了一个后果：请求砸向 Redis→ \rightarrow→没命中→ \rightarrow→请求全部穿透到 MySQL→ \rightarrow→MySQL 查半天发现也没有→ \rightarrow→无法回写 Redis（因为没数据）。

100 万个这种恶意请求直接绕过缓存防御，全部死磕在 MySQL 上。MySQL 瞬间 CPU 爆满、连接池耗尽，直接瘫痪，整个网站跟着一起崩溃。

有两种方法：

当mysql发现一个ID不存在时，不要什么都不做。我们在redis里为这个ID存一个特殊的空值。并设置一个较短的过期时间。那么接下来这个较短的时间中，再用这个ID来攻击时，redis就会直接返回null，请求就被拦截在缓存层了（但是这个方案，只要黑客不断变换攻击ID，照样会穿透，这只能防止某个ID被大量请求的情况）。
这才是真正有效的：布隆过滤器，这是一个极其高效的二进制数据结构。在请求到达Redis之前，先让布隆过滤器在最外层站岗。我们把数据库里所有已存在的商品ID全部通过哈希算法映射到布隆过滤器上（他只占极小的内存）。当黑客带着 ID = -999 连进来时，布隆过滤器一算，冷冰冰地告诉你：“这个 ID 绝对不存在于数据库中！” 连 Redis 都不用查，直接当场拒绝该请求。

击穿和穿透不一样，穿透是查不存在的数据，击穿是查一个非常热门的真实数据。

如果一个数据在redis里的访问量是每秒20w次。这个key在被疯狂访问的时候，刚好到了它在redis里设置的过期时间（TTL）。

就在这一秒钟，这个Key突然在Redis里蒸发了，而那每秒20w次的请求瞬间扑了个空。

20w个并发请求在同一秒内发现Redis没数据，只能同时涌入到Mysql里去查这条数据，面对这么多的并发，服务器瞬间宕机。

不设置过期时间。
对于这种预知到的超热点数据（比如春晚活动、双十一 iPhone 秒杀页面），在后台直接不给它设置过期时间，让它永久留在内存里。等活动结束了，后台再手动执行脚本异步把它们删掉。
互斥锁（Mutex Lock）
当 Redis 没命中时，不写命令让所有请求一拥而上。而是让第一个到达的请求去“抢一把互斥锁”（比如用 SETNX 抢锁）。
抢到锁的那个幸运儿，代表大家去 MySQL 查数据，然后把数据写回 Redis。而剩下的 19.9 万个请求，抢不到锁就原地睡 50 毫秒然后重试。当它们醒来重试时，Redis 里已经有那个幸运儿写回的数据了，直接完美命中！

如果说击穿是“精准爆破”打死一个点，那么雪崩就是“大面积塌方”，整座大山砸下来。

通常有两种原因会引发雪崩：

原因 1：运营人员做活动，在昨晚零点批量导入了 100 万个商品数据，并且顺手给它们设置了相同的过期时间（比如全是 1 小时）。结果到了今天凌晨 1 点，这 100 万个 Key 在同一秒钟集体过期。
原因 2： Redis 服务器由于硬件故障、断电或者网线被踢掉，直接挂机（宕机）了。
灾难：整个系统的缓存屏障瞬间消失（空了）。海量的用户请求失去了 Redis 的保护，如同雪崩引发的洪水，全量砸在底层的 MySQL 数据库上。MySQL 哪怕再强，也会在一秒内被连环冲跨，导致整个公司的业务全部瘫痪。

随机过期时间（Jitter）
原理：绝对不要让大批量的 Key 拥有相同的过期时间。我们在设置过期时间时，加上一个随机干扰值。
做法：比如原本要设 1 小时（3600秒），我们改成 3600 + rand(1, 300) 秒。这样，这 100 万个 Key 就会在 1 小时到 1 小时零 5 分钟之间慢慢地分批过期，请求被均匀拉长，MySQL 完全可以轻松撑住。
主从架构与哨兵集群
原理：单机版 Redis 太脆弱了。在线上必须部署 Redis 哨兵模式（Sentinel）或者 Cluster 集群。
效果：一旦主机（Master）断电挂了，哨兵会像“急救队长”一样，在 10 秒内自动把备用机（Slave）提拔为新的主机，继续支撑流量，不让系统崩盘。