我把公司的 Redis 打爆了！

你是小阿巴，一台兢兢业业的服务器。

所有用户的请求都由你来处理，大家都夸你稳定可靠。

但自从公司引入了 Redis 这个号称每秒能处理 10 万多次请求的内存数据库后，一切都变了。

大家都在夸它快、夸它强，用它来缓存数据，老板甚至说：“有了 Redis，服务器都不用升级了！”

你心里很是不爽：可恶的 Redis，竟然敢抢俺的风头，给你点颜色瞧瞧！

于是某天深夜，程序员鱼皮加班困得迷迷糊糊，你趁机夺舍了他的意识，开始制定一个《Redis 毁灭计划》……

⭐️ 推荐观看本文对应视频版，效果拉满：https://bilibili.com/video/BV1uPixBVEfC

第一招、疯狂建连

你心想：想要操作 Redis，要先和它建立连接，那俺就先从 连接 下手吧！

你翻看代码，发现这个狗鱼皮居然用了连接池，每次操作 Redis 都复用已有的连接。

你冷笑了声：哼，看俺把连接池给废了！

每次操作 Redis 都新建一个 TCP 连接，用完立刻关闭。

这样一来，每次请求都要经历三次握手建立连接、用完再四次挥手关闭连接，耗时暴增！

而且 Redis 默认最多只能接受 1 万个连接，只要我建立连接够多够快，就能占满它的连接数名额，让 Redis 拒绝新连接，直接返回错误！

你兴奋地想：哈哈，这下 Redis 要遭殃了~

等等，不对…… 频繁建立和关闭连接的开销，好像也会让我自己的 CPU 爆炸？

第二招、就不用批处理

你心想：不行不行，看来光建立连接还不够，俺要让每次请求都慢到极致！

你翻了翻代码，发现有个批量写入几万条数据的逻辑，狗鱼皮居然用了 MSET 和 Pipeline 这种高效的批处理命令。

你冷笑了声：哼，看俺把批处理逻辑改掉，用 for 循环一条一条 SET 几万条数据到 Redis。

这样一来，每条命令都要等网络传输来回一趟，这网络延迟（RTT）可不是闹着玩的，时间全浪费在路上了。

你得意地笑了：嘿嘿，Redis 你不是很快吗？这下你得陪俺耗到天荒地老了！

等等，不对…… 即使一条一条发请求，Redis 处理每条命令本身还是很快的，只是网络传输慢而已。真正累的还是俺自己啊！

第三招、扔个大 Key

你气的咬牙切齿：不行不行，前两招都是杀敌八百、自损一千，俺得来个真正能重创 Redis 的狠招！

Redis 你不是很能装吗？看俺给你扔个重磅炸弹！

俺要往一个 List 列表里塞 500 万条数据，制造一个超级大 Key，写入到你的内存中。

这样不仅会占用大量内存，而且网络传输也巨慢。

但这还不是最致命的，等到业务高峰期、Redis 最忙的时候，俺执行一个 DEL 命令删除它，引爆炸弹！

一次性删除 500 万条数据足够让你忙得焦头烂额了，而且因为 Redis 的命令执行是单线程的，删除期间所有其他命令都在排队等死，你就废了哈哈哈哈。

第四招、KEYS * 命令

你面露凶光：不行，光这样还不够狠！俺不仅要在高峰期压垮你，在你闲着没事干的时候，也得让你累死累活、忙得团团转！

俺记得有一些生产环境不能使用的禁术，嘿嘿嘿……

Redis 里现在起码有几千万个 key 了吧？那俺就执行 KEYS * 命令，一次性遍历整个 Redis 中的所有 key。

几千万个 key，扫描一遍估计得几分钟！

在这期间，Redis 单线程被完全占用，所有其他命令都只能乖乖排队。

大家会以为 Redis 挂了，实际上它在 “假死” 状态，忙着扫描呢，哈哈哈哈哈！

第五招、Key 集中过期

你转念一想：不过，KEYS * 这种慢查询很容易被监控工具检测出来，鱼皮老狗肯定会发现。保险起见，还得想个更隐蔽的招数。

俺记得 Redis 有两种删除过期 key 的策略：一种是惰性删除，访问时发现过期了才删。

另一种是主动删除，定期扫描过期 key。

具体来说，主动删除的机制是：每 100 毫秒扫描一次，随机抽取 20 个 key 检查，如果过期率超过 25%，就继续扫描，每次最多耗时 25 毫秒。

那如果俺设置 100 万个 key 同时过期，Redis 主线程就会持续忙于删除，让其他命令排队，基本废了！

哈哈，Redis 你就疯狂内耗吧。还有护着 Redis 的鱼皮老狗，头发掉光了也找不到原因，因为不是某个命令慢，而是 Redis 内部在疯狂删除。

第六招、缓存失效 3 连击

想了这么多损招，还是难解你心头之恨，于是你产生了更变态的想法：前面俺都是直接攻击 Redis，这次来点更狠的。俺不仅要让 Redis 自己废掉，还要破坏它的人际关系，让它身败名裂！

对了，Redis 不是在帮数据库缓存数据、减轻压力吗？那我就让缓存失效，所有的请求压力给到数据库，让数据库被打爆，到时候大家都会怪 Redis 没保护好它，哈哈。

方案一、缓存穿透

俺可以疯狂查询不存在的数据，比如 ID=-1 的用户信息。

如果 Redis 里没有，就去查数据库；数据库也没有，就会返回空。

但请求一直打过来，每次都要穿透 Redis 去查数据库，数据库肯定扛不住，老板会以为 Redis 在摸鱼呢~

方案二、缓存击穿

俺可以让一个超高频访问的热点 key（比如首页数据）突然过期。

然后大量并发请求瞬间打过来，发现 Redis 里没有，就会全部涌向数据库，数据库直接爆炸！

方案三、缓存雪崩

还可以让一大批 Redis 的 key 同时失效（其实就是前面第 5 步干的事），这样很多请求都会绕过 Redis 去查询数据库，数据库也会扛不住。

你得意极了：哼哼，这套三连招呼下来，哪怕你 Redis 自己没挂，也得背个大锅了！

第七招、内存杀手

前面那些招数都是立竿见影的，作为一个严谨且心狠手辣的服务器，你决定最后再来个慢性毒药，让 Redis 慢慢窒息而死……

你面露狡诈之色：我可以给所有的 key 都不设置过期时间，并且把 Redis 的内存淘汰策略设为 noeviction（禁止淘汰）。

这样一来，Redis 的内存会慢慢被吃满。等内存满了，Redis 会拒绝所有写入操作，然后业务全部报错。

想到这里，你忍不住狂喜：妙啊，好一手温水煮青蛙哈哈哈哈哈哈！

结局

你得意地看着这份完美的计划，并且把所有的代码改完：受死吧 Redis！你千不该万不该和我小阿巴作对！

你的面相都变了，冷笑一声，按下了执行键……

很快，Redis 的监控面板开始疯狂报警：连接数暴增、响应时间飙升、内存占用爆表，短暂的挣扎过后，Redis 抽抽两下，就彻底挂掉了。

你露出了宇智波狂笑：哈哈哈，Redis 不过如此嘛！

但没过多久，你发现自己越来越忙，甚至开始冒烟了。原来没有了 Redis 的缓存，每个查询请求都要去数据库查，响应慢了很多倍。于是请求越堆越多，你根本处理不过来，导致大量请求超时，用户疯狂投诉。

最终业务黄了，公司倒闭，你也即将被销毁，这时的你才幡然醒悟：害人终害己啊！