今天分享一个高频面试题：Redis 宕机了，如何恢复数据

下面我来模拟一个面试对话场景

✅ 面试实战演练

面试官

如果 Redis 宕机了，你怎么恢复数据？怎么保证业务不受影响？

候选人

好的，我一般会从 排查原因 和 恢复数据 两方面来处理。

一、排查 Redis 宕机原因

首先我会确定 Redis 为什么宕机，目的是防止恢复后再次宕机。

排查步骤：

1、查看 Redis 日志

内存溢出（出现 OOM）
磁盘写满（AOF 文件无法追加）
网络问题（大面积超时）
主从同步异常（慢日志、阻塞）
配置问题（如 appendfsync always 导致频繁 I/O）
进程被意外杀死（kill -9 或被运维误操作）

通常日志在 redis.log 文件中。

查看最后几条日志，分析是否是以下常见问题：

2、监控系统排查

内存使用率
CPU 占用率
慢查询（slowlog get）
主从同步延迟
磁盘 I/O

我们线上有监控工具（如 Prometheus + Grafana / zabbix）

重点看 Redis 节点的：

复现问题的可能性，必要时在测试环境验证。

如果是误操作导致

比如运维误删了数据（flushall），要从备份恢复，结合业务方补录数据。
生产环境要配置 protected-mode 和权限认证，防止误删。

二、数据恢复

Redis 宕机后，数据恢复依赖于持久化机制和高可用架构。

1. 持久化恢复方式

Redis 提供两种持久化方式：RDB 和 AOF。

AOF恢复

如果开启了 AOF 持久化，Redis 优先加载 AOF 文件。
我会先确认 AOF 文件是否完整，如果不完整或损坏：

redis-check-aof --fix appendonly.aof

修复之后重启 Redis 服务：

redis-server redis.conf

RDB（快照）恢复

如果没有启用 AOF，就需要依赖 RDB 文件（dump.rdb）。
我会确认 dir 配置目录中 dump.rdb 文件是否存在和有效。
如果有备份的 RDB 文件，拷贝过来，重启 Redis 加载快照文件：

# 复制备份到数据目录cp /backup/dump.rdb /data/redis/# 启动redis-server redis.conf

恢复后数据完整性验证

查看关键业务数据是否完整。
通过业务方接口和数据比对，确认恢复效果。

2. 其他节点同步恢复（高可用场景）

如果 Redis 是 主从复制 或 Sentinel（哨兵） 模式：

从节点保持数据同步，主节点宕机后，Sentinel 自动切换从节点为主节点。
这时可以直接从新主节点继续提供服务。

手动恢复：

# 将从节点提升为主节点redis-cli SLAVEOF NO ONE

如果是 Redis Cluster：

有多个分片节点，自动切换主从节点，保证服务不中断。
宕机节点恢复后会自动重新加入集群。

三、数据丢失的处理办法

如果出现数据丢失，视情况处理：

AOF 丢失

一般只丢失最近 1 秒的数据（appendfsync everysec）
如果 appendfsync always 配置，几乎不会丢数据，但性能差

RDB 丢失

RDB 快照一般是分钟级别间隔，丢失上次快照到宕机时间段数据。

数据补偿方法：

结合业务日志或数据库记录，人工或程序化补数据。
线上系统需做好数据补偿和幂等设计，确保恢复数据不会引发业务冲突。

四、总结日常预防手段

为避免类似问题再次发生，常规做法包括：

方案	作用
AOF+RDB 双重持久化	提供数据多重保障
AOF 策略配置 everysec	兼顾性能与数据安全
内存保护 maxmemory 和淘汰策略	防止 OOM
监控告警系统	实时监控 Redis 各项指标
Redis 主从+Sentinel/Cluster 部署	实现高可用
异地灾备，定期快照备份	防止数据丢失不可挽回
访问权限控制	避免误删和恶意攻击（`requirepass`、`ACL`）

✅ 面试官常问的追问 + 我的回答

面试官：你们生产 Redis 怎么做高可用？

答：

我们使用 Redis 主从复制 + Sentinel 保证高可用。
主节点宕机时，Sentinel 可以自动切换到从节点。
另外，采用了 异地容灾和备份机制，保证数据不丢失。
日常有 自动快照备份和冷备机制，重要数据异步写入数据库，防止单点丢失。

面试官m：你们怎么处理 Redis 宕机导致缓存穿透问题？

答：

缓存层宕机，流量会直打数据库。
我们有 限流和熔断 策略，比如用 Hystrix 限制流量。
还会用 布隆过滤器 防止缓存穿透，以及 队列缓冲 控制瞬时高并发流量。

面试官：Redis 的持久化机制会影响性能吗？

答：

会有一定影响，尤其是 AOF 的 appendfsync always 策略，性能最差但最安全。
生产环境我们用 everysec，通常性能影响可接受。
RDB 快照过程中占用内存和 CPU 资源，避免在业务高峰期执行。

✅ 一句话总结（面试结束时）

Redis 宕机数据恢复依赖持久化文件（AOF 和 RDB）以及高可用架构（主从、Sentinel、Cluster）。做好灾备、监控、权限控制、资源管理，才能最大限度降低故障风险和数据丢失。

🔥 你可以直接复述的答题模板

面试官你好，Redis 宕机后我会从两方面处理：

一是排查宕机原因，查看 redis.log，分析内存、磁盘、主从同步、配置等问题。
二是进行数据恢复。首先看是否开启了 AOF，Redis 优先加载 AOF 文件，如果损坏用 redis-check-aof --fix 修复。否则加载 RDB 快照恢复。如果有备份，可以拷贝备份文件恢复。
在主从或 Sentinel 架构下，可以直接切换从节点为主节点，保证业务不中断。
恢复后确认数据完整性，分析是否有数据丢失，结合业务日志做补偿。同时要分析宕机根因，优化配置，避免再次出现。
平时通过 AOF+RDB 双持久化、哨兵或集群高可用、监控和限流降级方案保证 Redis 的稳定性和数据安全。

关注小编，添加微信，可进入技术交流群。

往期推荐

高频面试题：Redis 宕机了，如何恢复数据