Redis单机模式服务器down了，最快恢复路径是重启服务并检查持久化数据，如果有AOF或RDB文件就能把数据找回来，后续治本方案是切换到哨兵架构或Cluster集群。
单机模式下Redis宕机后第一现场怎么判断
先分清是进程挂了还是整机宕了
服务器down这个说法比较笼统，常见情况有三种：Redis进程自己退出了、操作系统OOM把进程杀了、云服务器或物理机整体不可用，判断方法很简单，ssh登录服务器后执行systemctl status redis或者ps -ef | grep redis，能看到进程存在就说明问题不大，进程不存在，再看系统日志/var/log/messages或dmesg -T | grep -i oom确认是不是内存不够被杀。
进程还在但连接不上的排查顺序
有时候进程活着却连不上，这事更让人头疼，用redis-cli -p 6379 ping如果得到PONG说明Redis本身没问题，那就是网络或防火墙层面的事，检查云安全组是否把6379端口误关了，或者iptables规则有没有变动，本地连得上、远程连不上的情况，行业共识是要先检查安全组和iptables,这个顺序搞反了会浪费时间。
单机Redis宕机典型损失场景
单机模式下，Redis挂了最直接的后果是缓存全没了，命中率瞬间降到零，数据库被高并发流量硬抗，比如一个日活十万的电商网站，热点商品信息全在Redis里，突然宕机后数据库每秒几十倍请求涌入，很可能直接把主库打爆，据公开事故案例分析，相当一部分中小团队在Redis单机宕机时，只想着重启节点，忽略了持久化配置是否正确，结果数据擦掉后没法恢复,只能靠业务层回血。
重启Redis时的数据安全策略
先复制一份持久化数据再动手
这一步很多人跳过，但恰恰是最关键的保险，查看redis.conf里的dir和dbfilename配置，确认RDB快照文件的位置，然后用cp命令把dump.rdb复制到临时目录，如果开启了AOF，也要把appendonlyfile复制出来，为什么要备份？因为重启时如果AOF文件有损坏，Redis可能拒绝启动，你又没有原始文件可以排查,只能干瞪眼。
按优先级尝试三种启动方式
- 第一种：直接
systemctl start redis，能起来最好，起来后用redis-cli执行info memory和dbsize确认数据量是否正常。 - 第二种：AOF文件损坏导致无法启动，修改
redis.conf
把
appendonly yes改成no，先跳过AOF加载启动Redis，再用redis-cli -a 密码导出内存数据。 - 第三种：RDB文件也损坏了，把之前备份的dump.rdb放回
dir目录覆盖损坏文件，再启动,这种情况下能找回的数据取决去最后一次成功快照的时机。
Redis持久化配置怎么设才不会丢太多数据
这里直接说结论：只开RDB，最坏情况下会丢失从上次快照到宕机之间全部写入；只开AOF且用everysec策略，丢失窗口是一秒，行业共识认为，单机模式下想减少数据丢失，必须同时开启RDB和AOF，RDB负责快速加载备份，AOF负责记录每次写操作。appendfsync always性能消耗大不建议开，everysec在大部分业务场景下丢一秒数据是可接受的，用config rewrite命令把修改固化成文件,后续重启不会丢配置。
单机模式Redis高可用升级方案哪个好
哨兵模式是单机最头疼宕机问题的直接解药
单机改造成主从加哨兵，是当前命中率最高、成本最低的高可用升级路径，部署一套Sentinel集群至少三节点，自动监控主节点健康状态，在主节点挂掉时执行故障转移，把从节点提升为主节点，客户端连接Sentinel获取新主节点地址，整个过程不需要人工介入，相比单机模式，哨兵架构让”Redis服务器down了怎么办”变成了”Redis服务器down了Sentinel会自动处理”。
单机模式与集群模式的关键差异对比
| 维度 | 单机模式 | 哨兵模式 | Cluster集群 |
|---|---|---|---|
| 数据分片 | 无 | 无 | 有，16384个槽位 |
| 故障自动切换 | 无 | 有 | 有 |
| 容量上限 | 单节点内存上限 | 主节点内存上限 | 可横向扩展 |
| 部署成本 | 最低 | 低 | 较高 |
| 适合场景 | 个人学习、内部工具、QPS要求低 | 中小业务核心缓存 | 大规模高并发生产环境 |
如果你的业务还在单机阶段，又经常担心宕机问题，建议直接上哨兵架构，不必直接跳去Cluster，Cluster的运维复杂度和客户端改造成本都很高,对小团队来说性价比不划算。
手动故障转移的正确姿势
在过渡到哨兵之前，临时方案是先做手动切换，准备好一个从节点，用
replicaof 主节点IP 6379配置为备节点，主节点宕机后执行replicaof no one手动提升从节点为新主节点，然后改应用的Redis连接地址，这个操作需要业务侧配合，应用配置里把地址改为新主节点IP,或者用域名指向自动切换。
单机重启失败时的补救措施
数据恢复时的内存注意点
Redis加载AOF文件时会把所有命令全量重放，如果数据集比较大，内存占用可能超过原有水平，因为加载过程中会产生临时对象，启动前先free -g看下可用内存，不够就临时把maxmemory调低，或者先加载RDB（体积小加载快）再考虑AOF。
从备份文件恢复的实操路径
备份文件从哪里来？redis-cli --rdb dump.rdb可以把远端Redis数据拷贝到本地文件，SCP传回服务器放入dir目录重启即可，如果没有现成备份也没有从节点，就只能靠AOF残留数据做最后一搏，用redis-check-aof --fix修复损坏的AOF文件，修复后再启动，同样，redis-check-rdb dump.rdb可以校验RDB文件完整性。
单机Redis容灾备份方案是预防性底线
据云厂商公开文档，多数云Redis服务自带自动备份功能，但自建Redis单机没有这个福利，需要自己写crontab任务，每天定时执行BGSAVE生成RDB快照，再把快照传送到另一台机器或对象存储，这个步骤不能省，否则Redis服务器一旦物理损坏,数据就真的找不回来了。
单机模式宕机后客户端侧应该怎么做
连接池参数决定你的应用能否撑住Redis挂掉
不少应用在Redis挂掉后会表现为接口超时、线程阻塞，本质原因是连接池没设置合理的超时和容量参数，Java的Lettuce或Jedis连接池，建议maxTotal按QPS峰值估算，maxWaitMillis不要太大（几百毫秒足够），最关键的是开启熔断降级逻辑，比如把查询热点数据的逻辑改为查数据库+本地缓存兜底，统计显示，具备缓存降级策略的系统，在Redis宕机后服务瘫痪概率大幅降低,而没有降级策略的系统大概率整体不可用。
业务侧兜底逻辑如何设计
- 加本地缓存层：在应用内存中保留一份短TTL热点数据,Redis宕机后本地缓存先扛住一部分流量。
- 数据库限流：Redis挂了后所有请求涌向DB，数据库端要开启慢查询日志,必要时在中间件层设置流量限制。
- 人工熔断开关：大促场景下保留手动关闭某些非核心功能的开关,给核心业务腾出资源。
单机Redis宕机后能买到的商业替代方案
云托管Redis值得考虑的定价参考
很多人会问redis哨兵模式多少钱，实际上自建三节点哨兵和用云厂商托管Redis的成本差距并不大，以国内主流云厂商为例，基础版Redis 4G内存大约几十元/天，自带主从切换和自动故障恢复能力，省掉的运维人力成本早就超出了订阅费用，据IDC发布的行业报告，采用托管数据库服务的企业的故障恢复时间中位数比自建低大约一个数量级，对中小公司来说，Redis服务器down了这种事,交给云服务商处理比留一个大半夜爬起来的运维大哥更划算。
自建维护与托管服务的选择边界
如果你有专职运维且对数据安全问题敏感（比如金融行业必须私有化部署），自建哨兵是合理的，但如果只有一个后端团队兼管基础设施，托管Redis无疑更合适，数据可达性、安全审计、自动备份都是托管方案自带能力，可以说，单机模式本来就是为了省事而存在的，但真正出了事,自建的维护成本远超想象。
常见问题快答
Redis单机挂了且没有持久化文件还能恢复数据吗？
如果RDB和AOF都没有，内存数据在进程退出那一刻就已经丢失了，不存在恢复手段，剩下的唯一路径是检查操作系统级别文件（比如/proc下的进程内存转储），但效率极低且多数情况下不值得操作，唯一的教训是：务必开启持久化，并定期把RDB文件同步到异机,别等数据丢了才拍大腿。
Redis单机改为哨兵模式需要额外写代码吗？
不需要改业务代码，客户端库（例如Jedis、Lettuce、RedisTemplate）都原生支持通过Sentinel节点获取主节点地址，配置上把连接地址从redis://主机IP:6379改成sentinel://哨兵1地址:26379,哨兵2地址:26379,哨兵3地址:26379，并指定masterName即可，逻辑上应用不再直连Redis主节点，而是每次从Sentinel查询当前主节点,所以底层连接方式变化对业务代码完全透明。
单机Redis实例可以同时充当哨兵吗？
不建议，让Redis单机实例既保存业务数据又监控其他节点，一旦这台机器挂掉哨兵和主节点一起没了，高可用系统等于零，部署时把Sentinel放到另外的物理机或云主机上，至少保证挂一台不影响整体决策，这是一个架构职责划分的常识,不是性能问题。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/769323.html
