什么是冷备、热备，暖备？

面试考察点

1. 概念清晰度：面试官想知道你能不能把冷备、暖备、热备的区别讲清楚，而不是含糊其辞一通混。这三个词很多人只会背定义，真问起来又分不清。

2. 场景理解：光背概念没用，更关键的是——什么场景该用哪种？面试官想看你有没有 "花小钱办大事" 的意识，是不是真做过选型，别上来就堆热备双活。

3. 指标意识：高可用的核心指标 RTO（恢复时间目标）和 RPO（恢复点目标），这俩词能不能跟三种备份方式对应起来。提一嘴这俩指标，加分。

核心答案

先上一张对比表，三者的核心差异就在 "备机状态、数据同步方式、恢复速度、成本" 这几条上：

备份方式	备机状态	数据同步	恢复速度（RTO）	数据丢失（RPO）	成本
冷备	关机/未运行	不同步，靠定期备份文件	几十分钟～几小时	可能丢几小时数据	低
暖备	运行中，待命	异步/定期同步	几秒～几分钟	秒级～分钟级	中
热备	运行中，实时同步	实时同步，可自动切换	接近 0（自动切换）	几乎不丢	高

一句话总结：冷备 = 备机睡觉、热备 = 备机盯着、暖备 = 备机半睡半醒。

冷备暖备热备对比

深度解析

一、一张图看懂三者差异

冷备暖备热备切换流程

上图把三种方式的故障切换流程拆开了。重点看故障发生后的那一箭头：

• 冷备：故障 → 启动备机 → 恢复数据 → 切流量，整条链路最长，往往要几十分钟甚至更久。备机平时根本不跑业务。
• 暖备：备机一直开着，但数据是异步/定期同步的。故障发生时不用从零启动，直接把流量切过去，但可能有少量数据丢失或需要人工介入。
• 热备：备机和主机数据实时同步（通常用 binlog / WAL / Raft 这类机制），故障时由心跳检测 + 自动 failover 秒级切换，用户几乎无感。

二、结合实际，三者分别长什么样

冷备：典型场景就是数据库每天夜里备份出来的 dump 文件，丢到另一台机器或对象存储里放着。备机平时可能压根没开，等出事了再拉起来恢复。

我见过不少小公司内部系统就这么玩——一周一次全量备份，丢到 OSS 上，挂了就用备份恢复。RTO 几小时也能接受，毕竟不是核心链路。

暖备：MySQL 的异步主从、Redis 的主从复制，其实都算暖备。备机是活的，能接受读流量（读写分离就是这么来的），但故障切换往往要半人工或靠 MHA / Sentinel 这类工具辅助。

说个坑：很多人以为有了主从就万事大吉，其实异步复制在主机突然宕机的瞬间，未同步的那部分 binlog 就丢了。这就是 RPO 不为 0 的根源。

热备：典型代表是 Redis Sentinel 的自动故障转移、MySQL MGR（Group Replication）的强一致集群、Paxos/Raft 共识算法保障的多副本系统（比如 etcd、TiKV）。数据在写主的同时立刻同步到备，主机一挂，秒级选出新主。

成本也是最高的——机器要多，网络要稳，还得处理脑裂（split-brain）这种麻烦事。

三、RTO 和 RPO 这两个指标必须知道

面试官一提到高可用，RTO 和 RPO 是绕不开的：

• RTO（Recovery Time Objective，恢复时间目标）：系统从故障到恢复服务所需的时间。简单说就是 "能停多久"。
• RPO（Recovery Point Objective，恢复点目标）：故障发生时允许丢失的数据量。简单说就是 "能丢多少"。

对照一下：

指标	冷备	暖备	热备
RTO	长（小时级）	中（分钟级）	短（秒级）
RPO	大（可能丢几小时）	中（秒~分钟级）	小（接近 0）

四、怎么选？看业务

不要一听热备好就全堆热备，那得多贵啊。实际选型核心看两点：

1. 业务能不能停：核心交易、支付链路 RTO 必须秒级，那就得热备；内部报表、日志系统停半小时也无所谓，冷备就够了。
2. 数据丢不丢得起：钱相关的数据 RPO 必须接近 0，热备走起；日志类数据丢几分钟也没事，暖备/冷备即可。

我之前做过一个电商项目，订单核心链路是 MySQL MGR（强一致热备），日志和统计系统就一个 MySQL 主从（暖备）+ 每天冷备到 OSS。钱花在刀刃上。

面试高频追问

1. 追问一：热备一定不会丢数据吗？

   • 不一定。异步复制下的 "热备" 其实更像暖备；只有强一致共识算法（Paxos / Raft）保证多数派写入成功才算真热备，RPO 才接近 0。这里有个常见误区：很多人把 Redis 主从、MySQL 异步主从当成热备，严格来说是暖备。

2. 追问二：双活和热备是一回事吗？

   • 不完全是。热备通常是 "主-备" 模式，备机平时不接业务流量；双活是 "主-主" 模式，两个机房都接业务流量，都能写。双活比热备更复杂，要解决数据冲突、全局 ID、跨机房延迟等问题。

3. 追问三：脑裂（split-brain）是什么，怎么避免？

   • 主备之间网络断了，备机以为主机挂了把自己提成主，结果主机还活着——两个主同时写，数据就裂了。常用避免手段：引入仲裁节点（比如 ZooKeeper / etcd 的多数派投票）、fencing（直接把旧主隔离或断电，典型实现是 STONITH：Shoot The Other Node In The Head）。

常见面试变体

• "冷备、温备、热备有什么区别？"（注意有人叫 "温备" 不叫 "暖备"，一个意思）
• "MySQL 的主从复制属于哪种？"
• "你们生产环境用的什么容灾方案？为什么这么选？"
• "如何保证 RPO 为 0？"

记忆口诀

冷睡觉、暖半开、热盯着，故障来了——冷起床、暖上岗、热顶替。

RTO 从长到短、成本从低到高：冷 > 暖 > 热。

总结

冷备、暖备、热备本质是 恢复速度 vs 成本 的权衡。面试时把对比表说清楚，再带上 RTO/RPO 这两个指标，结合一两个实际中间件（MySQL 主从、Redis Sentinel、Raft），基本就稳了。记住一句话：没有最好的方案，只有最合适的方案——别一上来就热备双活，钱不是大风刮来的。