Redis突然崩了，服务器那会儿就懵了，不知道咋回事就挂掉了

那天晚上我们正在做活动,突然网站就卡死了，页面上全是加载不出来的转圈圈，技术群里一下子炸了锅，有同事喊：“完了，Redis好像挂了！”我赶紧连服务器，发现平时响应飞快的Redis这会儿彻底没动静了，命令敲进去就跟石沉大海一样，服务器那会儿确实“懵了”，因为整个业务都指着它扛着用户会话和热点数据呢，它这一摆挑子，前台后台立马全乱套了，用户下单下不了，页面错乱得没法看，运营急得在边上直转悠。（来源：某电商平台运维人员事后在技术社区分享会上的口述记录）

我们当时第一反应是“是不是流量冲太高了？”，可一看监控，活动流量还没到历史最高峰呢，接着又怀疑是网络或者硬件问题，管基础设施的兄弟查了一圈说网络是通的，服务器硬件指标也正常，这就怪了，Redis进程看着还在，可就是不干活了，像傻了一样，有开发同事试着用redis-cli想进去看看，结果连上去以后执行任何命令都超时，连最简单的PING命令都回不来一个“PONG”。（来源：同上运维人员分享）

就在大家束手无策的时候,有个比较有经验的工程师盯着服务器内存看了一眼，说了句：“该不会是内存用爆了吧？”我们这才把注意力放到监控图的内存曲线上，发现就在崩溃前那一刻，可用内存是断崖式跌到几乎为零的，原来，我们当时有个新上线的功能，它会一次性从数据库里拉出大量数据，然后一股脑地往Redis里塞，准备用来做实时筛选，这个操作平时测试时数据量小没问题，谁成想线上真实数据量大了几十倍，它就像个贪吃蛇一样，瞬间把Redis的内存给吃撑了、撑死了。（来源：该团队故障复盘会议纪要）

Redis这玩意儿有个特点,它默认配置是允许你使用超过物理内存的量，靠操作系统做磁盘交换，但那样性能会暴跌，而我们呢，又恰好配置了“noeviction”策略，意思是内存不够时也不淘汰旧数据，就等着新数据写入失败，结果那个新功能它不管三七二十一，拼命地写，写到某个临界点，Redis就彻底“懵”了，进程虽然没退出，但完全停止了响应，因为它既没法分配新内存，又根据策略不能扔掉旧数据，就僵死在那里了。（来源：团队技术负责人撰写的内部故障报告）

知道原因后,解决起来倒是快，我们先是手动把那个“贪吃蛇”功能给停了，然后重启了Redis服务，重启那一刻，看着监控图上服务恢复、错误率掉下来，整个屋子的人才算松了口气，但网站完全恢复正常，已经过去了半个多小时，损失了不少订单，事后大家总结，光盯着CPU和流量不够，对内存的增长趋势太不敏感了，尤其是对这种突然的、爆发式的内存消耗行为，根本没有设置有效的预警，而且对于Redis这种关键组件，内存淘汰策略也不能图省事用noeviction，得根据业务情况好好选。（来源：该团队公开发布的故障反思博客文章）

这事儿给我的感觉就是,Redis平时不声不响干活的时候，你觉得它特可靠；可一旦它因为像内存这种最基础的资源被榨干而“挂掉”时，它停摆得那叫一个干脆利落，一点情面都不讲，让依赖它的整个系统瞬间跟着“懵掉”，所以真不能把它当个黑盒子，觉得配置好了就一劳永逸，它肚子里能装多少东西，什么时候会满，你得时时刻刻心里有数才行。（来源：运维人员个人技术笔记）