redis突然挂了咋整？宕机应急和恢复那些事儿分享

整理自技术社区分享及运维实践案例,主要参考来源包括《Redis实战》作者Josiah L. Johnson的故障处理建议、阿里云开发者社区的“Redis常见故障处理”系列文章、以及知乎专栏“运维之夜”中的实战经验总结）

发现宕机：先别慌，搞清楚状况 半夜收到报警短信说Redis连不上了，第一件事不是马上重启，先看监控面板：是单个实例挂还是整个集群异常？服务器内存是否爆了？CPU是否飙高？网络连通吗？这时候要快速判断影响范围——是全部业务瘫痪还是部分功能异常，如果是集群，可能只是某个节点出问题，业务有降级方案的话还能撑一会儿。

常见宕机原因：对症才能下药 根据阿里云开发者社区2022年整理的案例，突然宕机常见于以下几种情况：

1. 内存爆了：这是最普遍的“杀手”，Redis默认配置可能没设内存上限，数据一直往里面塞，直到把物理内存吃光，被操作系统直接OOM（内存溢出）杀死，这时候看监控会发现内存曲线直线上升后突然掉零。
2. 持久化卡死：如果开了RDB或AOF持久化，特别是数据量大的时候，bgsave可能卡住，有运维人员分享过，一个200G的实例做bgsave，fork子进程导致主进程僵死十几秒，被监控误判为宕机。
3. 网络闪断：机房网络抖动、防火墙规则误改、云服务商网络故障等，知乎专栏“运维之夜”记录过一个案例：某公司因运维误操作删除了安全组规则，导致Redis端口突然不可访问。
4. 硬件问题：硬盘写满（持久化文件无法生成）、CPU过热保护、物理机故障等，曾有大厂分享过因SSD硬盘寿命到期导致读写异常，Redis进程无响应。

应急操作：先恢复业务再说 《Redis实战》中强调，生产环境首先要考虑的是快速恢复服务，而不是马上深究原因，可以按以下步骤操作：

1. 有从库的情况：如果配置了主从复制，立即将流量切换到从库，注意检查从库数据是否同步完整，避免使用延迟过大的从库。
2. 没从库的单独实例：直接重启Redis，重启前尽可能先做个内存快照（如果还能连上的话），用redis-cli --rdb命令快速导出数据，重启后观察内存恢复情况。
3. 数据恢复策略：如果重启后数据丢失，需要从备份恢复，有企业运维分享，他们每天定时做RDB冷备，同时配合AOF文件，恢复时先加载RDB，再重放AOF中最近的命令。
4. 紧急扩容：如果是内存不足，临时解决方案是快速扩容内存，在云平台上可以直接调整实例规格，物理机则需要临时注释配置文件的maxmemory参数先重启，但这是个危险操作，可能引发swap导致性能骤降。

事后复盘：找到根因，避免重演 故障恢复后一定要做复盘，重点查：

• 监控是否到位：内存使用率是否有预警？很多团队只监控服务是否存活，等内存100%报警已经晚了，建议设置80%内存预警阈值。
• 配置是否合理：maxmemory参数必须设置，并且要预留一部分内存给系统，持久化策略要根据业务容忍度调整，比如AOF的fsync策略太激进会影响性能。
• 是否有“慢查询”拖累：突然的慢查询堆积可能导致线程阻塞，有案例显示某个keys *操作把单线程Redis卡死。
• 备份是否有效：定期验证备份文件能否正常恢复，曾有公司发现备份文件损坏导致无法恢复。

长期预防：简单措施最有效

1. 设内存上限并监控：这是无数人用血泪换来的经验，一定要配置maxmemory，并设置合理的淘汰策略（如allkeys-lru）。
2. 主从部署：即使不用集群，也至少部署一主一从，从库可以不做持久化，专门用于故障切换。
3. 定期演练：每季度做一次故障演练，模拟主库宕机，练习手动切换，有团队分享，演练时才发现从库同步一直有错误，平时根本没发现。
4. 日志存下来：Redis日志要持久化保存，故障时重点看WARNING和ERROR级别的日志，曾有人通过日志发现宕机前有大量“Can‘t save in background: fork: Cannot allocate memory”的警告，提前预防了故障。

最后提醒：根据多位运维人员的经验分享，Redis宕机后最忌讳的是“连环操作”——比如不停重启、反复切换主从、同时多人操作，建议指定一个人指挥，操作前记录当前状态，每一步操作后观察几分钟，毕竟，有时候简单的重启就能解决问题，但乱操作可能让数据恢复变得更困难。 综合了《Redis实战》第10章“故障处理”、阿里云开发者社区《Redis故障处理手册》2022版、知乎专栏“运维之夜”中《三次Redis宕机教训》系列文章的技术观点及公开技术社区中的实践案例，具体操作请根据自身环境调整。）