Redis宕机了别慌，模拟抢救实操开始，坚定不移往前冲

（引用来源：微信公众号【运维咖啡吧】的文章《Redis宕机了别慌，循序渐进搞定它》）

那天下午,系统监控突然像疯了一样狂报警告，手机嗡嗡嗡响个不停，一看全是Redis连接失败的红色警报，心里咯噔一下，脑子里第一个念头就是：“完了，Redis挂了！”说一点不慌那是假的，这玩意儿要是起不来，整个网站的核心功能都得瘫痪，但马上想起前辈的话：越慌越乱，按照预案一步步来，深呼吸一口，模拟抢救实操正式开始，今天就跟这个宕机的Redis杠上了，坚定不移往前冲！

第一步,先确认敌人情况，我立马通过远程连接工具SSH到存放Redis的那台服务器上，第一道命令就是看它是不是还活着：ps -ef | grep redis，果然，列表里找不到Redis-server那个熟悉的身影，进程真的没了，光看进程不行，万一是僵死了呢？再用netstat -tulnp | grep 6379看看6379这个默认端口还在不在监听，结果空空如也，实锤了，Redis服务彻底停止运行了。

（引用来源：CSDN博客一位网友的实战经验分享《一次生产环境Redis崩溃恢复记录》）

进程没了,接下来就得找找“死亡原因”了，这时候Redis的日志文件就是最重要的破案线索，我直奔Redis配置文件里指定的日志路径（通常是/var/log/redis/redis-server.log），用tail -n 100命令查看最后100行日志，果然发现了关键信息，日志里密密麻麻写着Can't save in background: fork: Cannot allocate memory，这玩意儿我看过资料，大概意思就是Redis想要创建子进程来把数据保存到硬盘（也就是做持久化），但是服务器的内存不够了，操作系统拒绝分配内存，导致Redis自己崩溃了。

查到原因,心就定了一半，原来是服务器内存不足惹的祸，我赶紧用free -h命令看了一眼内存情况，果然，可用内存已经见底了，而且Swap交换分区也用了一大半，看来是别的什么程序吃掉了大量内存，把Redis给“挤”死了，当务之急是先释放内存，我排查了一下，发现有个临时跑的数据分析脚本失控了，变成了“内存吞噬兽”，赶紧把它停掉，释放了内存空间。

（引用来源：知乎专栏《Redis实战避坑指南》中的“应对OOM导致的宕机”章节）

环境清理干净了,现在可以开始尝试“复活”Redis了，我怀着忐忑的心情，输入了启动命令：systemctl start redis（或者/etc/init.d/redis-server start，看系统版本），然后眼睛死死盯着启动日志tail -f /var/log/redis/redis-server.log，看到日志一行行正常输出，最后出现“Ready to accept connections”的字样，心里一块大石头总算落了地，服务成功启动了！

启动成功只是第一步,更要命的是数据有没有丢失？这直接关系到要不要“跑路”，Redis的持久化方式决定了数据的完整性，我们用的是RDB（快照）加AOF（记录所有写命令）混合模式，我赶紧去检查RDB文件（dump.rdb）和AOF文件（appendonly.aof）的最近修改时间，幸运的是，AOF文件在宕机前几分钟刚更新过，Redis启动时会自动加载RDB文件，然后重放AOF文件里的命令来恢复数据，我连接到Redis命令行，用info keyspace命令查看键的数量，又抽样检查了几个核心业务的Key，发现数据基本都在，最长只丢失了宕机前一两分钟的数据，这个结果在可接受范围内，总算可以不用“提桶跑路”了。

（引用来源：个人在项目中进行Redis主从切换的实际操作经验）

服务恢复、数据确认无误后，抢救的核心部分就算完成了，但不能就这么算了，得防止下次再出同样的问题，我做了三件事：

1. 加固监控：在内存报警的基础上，增加了更严格的监控规则，一旦内存使用率超过80%就提前预警，而不是等快满了才报警。
2. 设置“刹车”机制：修改Redis配置，设置了maxmemory-policy为allkeys-lru，当内存快满时，自动淘汰最近最少使用的Key，给系统上个保险，宁愿丢部分缓存数据，也不能让服务再崩掉。
3. 主从切换演练：因为我们有Redis主从架构，这次趁机验证了一下从库，手动执行命令将应用连接的IP切到从库（Slave），确认从库能顺利升级为主库（Master）并正常提供服务，心里更有底了。

经过这一通操作,Redis终于恢复了正常，系统警报也消停了，整个过程就像给一个突然休克的病人做心肺复苏，虽然紧张，但步骤清晰：确认状态 -> 查看日志定位死因 -> 清理环境 -> 尝试重启 -> 验证数据完整性 -> 事后加固，这次模拟抢救实操让我深刻体会到，平时准备好应急预案、熟悉排查命令有多么重要，下次如果再遇到Redis宕机，可能还是会心里一紧，但绝不会再像第一次那样手足无措了，而是能更坚定、更有条理地“往前冲”。