高并发压垮Redis到底是怎么回事，宕机背后那些没说清楚的秘密

（引用来源：部分观点和案例参考了微信公众号“码农翻身”和“阿里技术”的相关文章,并结合行业普遍认知进行阐述）

高并发压垮Redis这件事，听起来很技术，但我们可以把它想象成一个非常繁忙的十字路口,而Redis就是这个路口的唯一一个超级交警。

这个交警（Redis）的能耐是有限的，他的大脑能同时处理的事情就那么多，比如他同一秒钟只能记住一百辆车的通行指令（这指的是Redis单线程处理命令的特性，以及有限的网络连接数和每秒操作数QPS），在平时，车流量不大，交警指挥得井井有条，所有车都能快速通过，路口（系统）非常顺畅。

突然有一天，附近有个商场搞特大促销（这就是业务高峰，比如双十一秒杀、热点新闻事件），成千上万辆汽车（海量的用户请求）瞬间从四面八方涌向这个路口，它们都急着要通过，不停地按喇叭（向Redis服务器发送请求）。

这时候,问题就开始一层层暴露出来了：

第一层：交警忙到崩溃，请求的数量远远超过了交警大脑的处理极限，他来不及处理所有的指令，新的指令又源源不断地涌来，结果就是，大部分车辆都堵在了路口，动弹不得（请求堆积，响应时间急剧上升，甚至超时），从司机的角度看，就是App卡住了，页面刷不出来，交警本人也因为高度紧张和过载，濒临“崩溃”边缘（Redis服务器CPU负载极高）。

第二层：更糟糕的连锁反应，这个交警（Redis）并不是孤立的，他指挥的车辆，最终是要去各个商家的（比如数据库MySQL），在正常情况下，交警会先查一下小本本（Redis是缓存，存储热点数据），如果小本本上有记录，就直接放行；如果小本本上没有，他才会打电话问总指挥部（后端数据库），现在路口全堵死了，所有车都停着，但有些请求是交警的小本本上没有的，必须问总指挥部，在拥堵中，这些需要查询总指挥部的请求也在排队等待，更可怕的是，如果这时候，最初设计时有个失误：比如当交警的小本本里查不到数据时，系统会默认同时派好几辆车去总指挥部问同一个问题（这就是常见的“缓存击穿”或“缓存雪崩”场景），这下好了，路口本来就堵，还突然产生了大量通往总指挥部的额外电话，直接把总指挥部（数据库）的电话也打爆了，数据库可比Redis要“娇贵”得多，处理并发的能力更弱，一旦被打垮，整个系统就彻底瘫痪了，这就是所谓的“缓存雪崩”，一个节点宕机,引发全系统宕机。

第三层：秘密在于“压垮”的方式，很多人以为压垮Redis就是简单的“流量太大”，但现实中，往往不是正面的“洪水”冲垮的，而是很多被忽略的“暗流”。

• 大Key攻击： 想象一下，不是来了一万辆车，而是来了一辆超级巨无霸卡车，车上装满了货物（一个Value体积巨大的Key，比如一个包含几十万元素的集合），交警处理这一辆车的通行指令，所花的时间相当于处理几百辆普通小车，这样一个大Key就能严重拖慢整个路口的通行效率,让其他车等得更久。
• 复杂命令拖慢： 有些指令本身就很复杂，比如让交警对路况做一个全面的统计分析（使用KEYS *这样的命令，或者对一个大Key进行排序SORT），在车流量小的时候，做一下还行，但在高并发时，这个命令会长时间占用交警的大脑，导致期间所有其他简单指令（比如GET、SET）全部等待,瞬间造成拥堵。
• 连接数耗尽： 每个司机和交警建立沟通渠道（网络连接）是需要资源的，Redis能同时维持的连接数是有限的，如果瞬间有十万个司机试图和交警建立联系，而交警只能同时和一万人说话，那么剩下的九万人连“喂喂喂”都喊不出口，直接就被拒绝了，感觉就是服务完全不可用,这比排队等待还要糟糕。
• 网卡被打满： 即使交警大脑还能转，但路口通往交警耳朵的那条通信线路（服务器网卡带宽）是有限的，海量的请求和数据返回，可能先把这条物理线路给塞满了，数据包开始丢失，交警听到的都是断断续续的指令,无法正常工作。

高并发压垮Redis的“秘密”，不仅仅是流量大这个表面原因，更深层的是在高压之下，平时不显眼的设计缺陷、不良的编程习惯（滥用大Key、复杂命令）、以及对Redis自身极限（连接数、内存、网络）的不了解，共同作用导致了系统的崩溃，它往往是一个从响应变慢开始，到请求堆积，再到引发连锁反应，最终导致数据库宕机的灾难性过程，防止这种情况，不能只想着给交警打鸡血（单纯提升硬件），更要从限流、优化命令、避免大Key、设计降级方案等全方位入手。