应用服务器做热备，核心是把心跳检测、共享数据、切换脚本和回切验证做成闭环，主备节点通过VIP或负载均衡对外提供一致服务，故障时自动接管，平时靠演练验证RTO和RPO。
热备不是装个软件就完事,应用服务器承载的是业务进程、会话、上传文件和数据库连接，任何一项没对齐，切换过去也可能“机器活着、业务躺着”，下面按架构、落地、成本、云上场景和故障排查拆开讲。
应用服务器双机热备怎么做？先定架构再落地
主备、双活、集群：三种架构怎么选
| 架构 | 资源利用率 | 切换速度 | 适用场景 | 成本 |
|---|---|---|---|---|
| 主备 | 备用机平时闲置 | 秒级到分钟级 | 中小业务、单套核心应用 | 中 |
| 双活 | 两台都承载流量 | 秒级到分钟级 | 访问量较大、要求连续服务 | 较高 |
| 集群 | 多节点分担流量 | 秒级到分钟级 | 可横向扩展的Web应用 | 高 |
主备适合大多数传统应用服务器,双活和集群更适合前端Web层，数据库仍要单独做主从或主备，选型时先问三个问题：应用是否无状态、会话能否集中存储、数据库切换是否同步，三个答案决定热备能做到多“热”。
Keepalived+VIP落地路径
Linux应用服务器最常用的双机热备组合是Keepalived加VIP,两台机器都装Nginx或Tomcat，Keepalived负责漂移虚拟IP，健康检查脚本负责判断应用端口是否可用。
关键配置路径在/etc/keepalived/keepalived.conf：
vrrp_instance VI_1里设置state MASTER和state BACKUP，主备priority拉开差距virtual_router_id两边保持一致，authentication用简单密码virtual_ipaddress写对外VIP，例如168.10.100/24track_script调用应用健康检查脚本，不要只检查网卡
健康检查脚本可以这样写：
#!/bin/bash
code=$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/health)
if [ "$code" = "200" ]; then
exit 0
else
exit 1
fi
上线命令：
systemctl enable keepalived systemctl start keepalived ip addr show tail -f /var/log/messages
备机切过去后,用ip addr确认VIP是否漂移，再用curl http://VIP/health确认业务端口，业内专家指出，VIP漂移成功不等于业务切换成功，必须把应用健康检查挂进Keepalived，否则网卡活着、进程死了也会误判。
共享存储与会话保持：切换后用户不掉线
应用服务器热备最容易忽略的是“状态”，用户登录后会话在本地内存，切到备机就掉线；上传文件在主机的本地磁盘，备机读不到，常见做法：
- 会话集中存到Redis,应用配置
session指向Redis地址 - 上传目录挂NFS或对象存储,两台应用服务器挂同一路径
- 数据库做主从,应用连接串配VIP或域名，切换时改指向
- 应用尽量无状态化,日志和临时文件不落本地盘
共享存储要配开机自动挂载,并在切换脚本里加mount -a检查，挂载失败时应用启动会报错，反而暴露问题。
应用服务器热备和冷备有什么区别？场景选型与预算参考
热备与冷备对比：切换时间与成本
热备是备用机常备、数据同步、可自动接管；冷备是备用机平时关机或只装系统，故障后人工恢复，区别不在“有没有备用机”，而在“切换要多久”。
| 项目 | 热备 | 冷备 |
|---|---|---|
| 切换时间 | 秒级到分钟级 | 分钟级到小时级 |
| 数据新鲜度 | 实时或准实时 | 依赖备份恢复 |
| 资源成本 | 备用机常备，成本较高 | 备用机可复用，成本较低 |
| 运维要求 | 需要心跳、脚本、演练 | 需要备份、恢复手册 |
| 适用场景 | 核心业务、连续服务要求高 | 内部系统、可接受停机 |
行业共识认为,核心交易和对外服务优先热备，后台报表和内部OA可以冷备加备份，把冷备当热备用，故障时才发现恢复手册没人练过，这是常见坑。
中小企业应用服务器热备方案多少钱？成本构成拆解
预算不要只问“一套热备多少钱”，要拆成四块：
- 服务器或云主机：主备两台，备机规格可略低，但不能低到切过去扛不住
- 共享存储：NFS、分布式存储或对象存储，按容量和请求量计费
- 负载均衡或VIP：云上SLB按实例和流量计费，自建VIP主要算运维人力
- 演练与运维：切换脚本、监控告警、定期演练，这部分最容易被漏算
自建双机的隐性成本是备用机闲置,云上按量付费和抢占式实例可以降低备机成本，但要注意抢占式实例被回收时不能影响主链路，近年来，不少中小企业把热备做成“云上多可用区+负载均衡”，比自建双机更轻。
北京应用服务器热备部署服务怎么选？
选本地部署服务,重点看四件事：
- 是否提供切换演练报告,而不是只交配置
- 是否覆盖应用健康检查、数据库切换、共享存储挂载
- 是否配监控告警,VIP漂移、端口不可用、数据库延迟都要有阈值
- 故障响应是否落到合同SLA,本地团队能不能到场
北京地区服务商不少,差别在“交付配置”还是“交付可演练的热备”，让对方现场做一次计划内切换，比看方案PPT有用。
云上应用服务器热备怎么做？多可用区与负载均衡
云上热备的落地路径
云上不必照搬Keepalived,多数云环境限制组播和VIP漂移，更稳的做法是负载均衡加多可用区：
- 在两到三个可用区各部署一台应用服务器
- 负载均衡后端挂两台机器,健康检查路径配
/health - 健康检查间隔设短一些,超时和不健康阈值按业务容忍度调
- 数据库用云托管主备或主从,应用连接串走内网域名
- 上传文件放对象存储,会话放Redis，应用服务器保持无状态
健康检查不要只查TCP端口,端口通但应用返回500，负载均衡仍可能把流量打过去，配HTTP健康检查，返回200才算健康。
云上热备的坑
- 安全组没放通备机,切换后VIP通了但端口不通
- 会话没集中存储,切过去用户重新登录
- 数据库主备切换后应用连接池没刷新,报连接超时
- 对象存储权限没配好,上传文件404
- 只做云主机高可用,没做应用层健康检查
据工信部公开信息,企业上云过程中，容灾演练和业务连续性被反复提及，云平台提供的是基础设施高可用，应用层热备仍要自己设计。
热备切换失败怎么排查？五个高频故障点
- VIP没漂移：查
vrrp_instance状态、priority、virtual_router_id和防火墙是否放通VRRP协议，用ip addr确认VIP落在哪台机器。 - 健康检查误判：脚本返回码不对，或检查路径需要登录，先用
curl -I http://127.0.0.1:8080/health手动验证。 - 共享存储没挂上：备机执行
mount -a，检查NFS服务端导出权限和客户端防火墙。 - 会话丢失：确认Redis地址在主备一致，应用启动日志里session配置是否生效。
- 数据库没切：应用连接串还指向原主库，或连接池没刷新，切换后重启应用或刷新连接池，检查
show slave status延迟。
排查顺序建议从VIP到应用端口,再到存储和数据库，先保证流量能到备机，再保证备机能读数据。
上线前必须做的热备演练与监控
热备上线前至少做四类演练：
- 计划内切换：手动停主节点Keepalived，观察VIP漂移和业务恢复时间
- 进程故障：
kill应用进程，看健康检查是否触发切换 - 网络故障：断开主节点网卡，验证心跳超时和脑裂保护
- 存储故障：卸载共享存储，确认应用是否报错、监控是否告警
监控要覆盖VIP状态、应用端口、接口返回码、数据库延迟、共享存储挂载点，告警阈值不要只配CPU，热备最怕“资源正常但业务不可用”。
热备的价值不在配置多漂亮,而在故障那天能不能自动切、切过去能不能用，把切换脚本、健康检查、共享数据和演练记录做成闭环，应用服务器热备才算真正落地。
应用服务器热备常见问题Q&A
Q1：应用服务器热备必须用共享存储吗？
不一定，无状态应用可以把会话放Redis、文件放对象存储，应用服务器本身不存业务数据，有状态应用才需要共享存储或数据复制，判断标准是：备机启动后能不能独立读到主机的业务数据。
Q2：热备切换后原主恢复，要不要自动回切？
建议手动回切或延迟回切，自动回切容易在数据未同步时造成脑裂和双写，计划内回切先停备机流量，确认数据同步，再切回主节点。
Q3：云上还有必要自己搭Keepalived吗？
多数云环境不需要，负载均衡加多可用区加健康检查已经能覆盖应用层热备，自建VIP在云上常受网络限制，只有云下IDC或特殊网络环境才考虑Keepalived加VIP。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793832.html
