Redis内存突然暴涨崩溃到底是咋回事，血崩到底指啥问题？

Redis内存突然暴涨直到崩溃，这个问题说白了就像是你的一个小仓库，平时规规矩矩地放东西，空间够用，但突然有一天，不知道为啥，海量的货物被一股脑儿地塞了进来，瞬间把仓库撑爆了，连门都打不开了，整个仓库系统彻底瘫痪，这个“血崩”，指的就是这种短时间内内存使用量像雪崩一样急剧上升,最终导致Redis服务彻底挂掉的灾难性现象。

到底是什么原因会导致这种“血崩”呢？根据网络上众多开发者的经验分享和官方文档的提示，主要有以下几个常见的“罪魁祸首”：

第一，大Key的突然出现或爆发。 这是最常见的原因之一，所谓“大Key”，就是指某个Key对应的Value值特别大，比如一个String类型的Key存了几兆甚至几十兆的数据（可能是一个巨大的JSON字符串或图片的Base64编码），或者一个List、Hash、Set集合里面积累了成千上万甚至百万级的元素，平时可能没事，但如果业务上突然需要读取或操作这个“大Key”，问题就来了，你用了个 HGETALL 命令去获取一个包含几十万字段的Hash键，Redis需要一次性把所有数据都捞出来并返回给客户端，这个过程不仅极度消耗网络带宽，更关键的是，Redis是单线程的，它在处理这个超级耗时的命令时，会阻塞住所有其他命令的执行，更可怕的是，如果这个操作触发了Redis的内存淘汰机制，试图清理出一些空间，但清理的速度远远赶不上这个大Key占用的速度，或者因为阻塞导致淘汰动作也无法及时进行,内存就会在瞬间被撑满。

第二，不当的内存淘汰策略配置。 Redis允许你设置当内存用满时，如何处理新来的写入请求，如果你把它设置成了 noeviction（不淘汰）策略，那么当内存达到上限时，所有尝试写入的命令都会报错，这听起来好像能防止内存爆掉，但实际上，如果同时存在上面说的大Key操作，或者有持续的大量写入请求，内存可能已经在临界点了，任何一个稍大的操作都可能成为压垮骆驼的最后一根稻草，而如果设置的是其他淘汰策略（如LRU），但在内存压力极大时，淘汰（删除键）这个动作本身也需要消耗CPU资源，如果淘汰的速度跟不上新数据写入的速度，同样会导致内存只增不减,迅速崩溃。

第三，Key集中过期导致的缓存雪崩。 这就是“血崩”一词非常经典的场景，想象一下，你在Redis里给大量的Key设置了相同的过期时间（比如都是凌晨1点过期），当这个时间点到来时，这些Key会在极短的时间内集体失效，这时候会引发两个连锁反应：Redis需要同时删除这些过期的Key，这个批量删除的动作会瞬间消耗大量CPU资源，可能导致服务短暂无响应，也是更致命的，所有这些Key对应的数据在缓存中都不存在了，那么下一秒，所有的用户请求都会像洪水一样直接冲向后端的数据库（比如MySQL），数据库根本承受不住这种瞬间的巨量查询压力，很可能直接被打挂，数据库一挂，应用系统也就跟着瘫痪了，虽然Redis本身可能因为删除了大量Key而释放了内存，但整个系统已经崩溃了，这同样是一种“血崩”式的灾难。

第四，持续的内存泄漏。 这种问题比较隐蔽，但危害巨大，它指的是Redis占用的内存在业务平稳的情况下，也会持续地、缓慢地增长，最终还是会爆掉，这通常不是Redis自身的Bug（虽然极少数版本可能有）,更多的是使用不当。

• 客户端连接泄漏： 应用程序创建了Redis连接，但用完后没有正确关闭，这些“僵尸连接”会一直占用Redis服务器的内存和资源，连接数越来越多,内存就被慢慢耗尽了。
• 不当的持久化操作： 当Redis执行RDB快照或AOF重写时，会fork一个子进程来操作，在Linux系统下，fork采用的是写时复制机制，如果此时父进程（主Redis进程）有大量数据被修改，就会产生内存的额外开销，导致内存用量短暂飙升，如果本身内存就紧张，这次飙升就可能直接触发OOM（内存耗尽）。
• 不合理的命令使用： 比如一直使用 KEYS * 这种模糊查询命令，在生产环境数据量大的情况下,这个命令会阻塞线程并消耗大量资源。

Redis内存暴涨崩溃（血崩）的本质，往往是短时间内无法处理的数据量（写入、读取、删除）远远超过了Redis单线程的处理能力和内存容量，再结合可能存在的配置不当或使用姿势错误，最终导致了服务的彻底失效，要避免这种问题，关键就在于预防：避免产生大Key、给Key的过期时间加上随机值以防止同时失效、选择合适的淘汰策略、监控内存和连接数的变化、使用 SCAN 替代 KEYS 等。