别再把所有服务器都堆成双机热备了，高峰业务该做多重冗余，完全由你能接受多久不服务决定。
先搞清楚：冗余不是越满越好，是越匹配越好
做运维最怕听到一句话：“这系统重要，给我上最好的。”什么叫最好？双机热备、负载均衡、异地多活、同城双活，全上？预算吃不吃得消先不说,架构复杂度本身就会成为新的故障源。
行业共识认为，冗余的本质是用成本换时间，你愿意为“不发生服务中断”这件事付出多少机器、多少带宽、多少人力，取决于业务中断一次会带来多大损失，这不是技术选型问题,而是风险定价问题。
很多团队第一步就搞反了：不从业务倒推冗余级别，而是先订机器再做架构,做之前先回答三个问题：
- 如果这个服务挂了，30秒内恢复能接受，还是5分钟后恢复能接受？
- 极端情况下丢多少数据你能容忍？一分钟的订单记录,还是一整天的日志？
- 一次故障的连带影响，是损失几笔交易,还是让核心链路全部堵死？
把这三个答案写出来,冗余方案自然就有了雏形。
风险接受度：决定冗余层级的唯一标尺
先给业务分级，再谈冗余设计
没有业务是平等的，一次大促中，商品详情页、购物车、订单支付、库存扣减，每个环节的故障容忍度完全不同,直接分四个等级：
| 业务等级 | 典型场景 | 可接受停机时长 | 可接受数据丢失 |
|---|---|---|---|
| S级 | 支付、订单、库存 | 不可接受（秒级切换） | 零丢失 |
| A级 | 购物车、用户登录 | 1-2分钟内 | 极少丢失 |
| B级 | 商品详情、评论、搜索 | 5-10分钟 | 短期丢失可接受 |
| C级 | 后台报表、历史归档 | 小时级甚至隔天 | 单次任务重跑即可 |
分级做完你会发现，真正需要“双机+实时同步+自动切换”这套高成本方案的，只有S级和一小部分A级业务，剩下的,完全可以用更轻量的手段兜住。
RTO与RPO：废掉“拍脑袋决定”的两个硬指标
冗余程度从来不是感觉出来的，是两个数算出来的。RTO（恢复时间目标）告诉你系统最长能瘫多久，RPO（恢复点目标）告诉你最多能丢多少数据，把这两个数定下来,方案直接按表查。
- RTO小于30秒，且RPO为零：只有同步复制的双活或主备切换能满足。
- RTO在5分钟内，RPO在分钟级：异步复制的主备模式就够。
- RTO在半小时以上，RPO允许丢一段时间：冷备+定期备份，成本最低,可靠性完全够。
业内专家指出，相当一部分非核心业务的故障，根本不是靠高可用架构扛过去的，而是靠快速重拉容器、重启进程、回滚版本解决的，与其花大价钱堆机器,不如把发布流程和自动恢复脚本做扎实。
三套主流冗余策略，按业务等级对号入座
市面上喊得花哨的“同城双活”“异地多活”，拆到底层无非三种模式的组合，理解了这三种，服务器双机热备和负载均衡区别自然就清楚了前者解决“挂了能不能顶上”，后者解决“流量能不能摊开”。
冷备给“不重要但得有”的业务兜底
适用对象：C级业务、内部管理系统、报表服务。
形态：一台同配置服务器，定期从主服务器同步数据包，或者干脆只做系统镜像，主服务器宕机，手动把IP指过去,30分钟到1小时内拉起服务。
成本：一倍机器费用，但不需要实时同步的带宽开销,也不需要额外的仲裁节点。
这个方案的陷阱是备机常年不启动，系统补丁、中间件版本、配置文件早就和主服务器不一致了，真到切换那天，备机很可能起不来。实操要求是每季度做一次备机启动演练，别让“备份”变成“悲愤”。
热备99%的高峰业务，做到这里就够了
适用对象：A级业务、B级里对实时性有要求的业务。
形态：主备两台机器，通过心跳检测互探状态，主服务器宕机，备机自动接管虚拟IP和对外服务，切换时间一般在30秒到2分钟之间，常见架构是Keepalived+Nginx,数据库用主从同步。
说几个具体操作：
- 主备机器必须放在同一台交换机下，避免网络分区导致两边互相以为对方死了,同时争抢VIP。
- 心跳网口和管理网口要分开,别让业务流量把心跳线路堵死。
- 每半年做一次主动切换演练：把主服务器的网线直接拔了,看备机能不能扛起来。
这里特别注意：热备的“备”是空闲的，平时不承接流量，机器配好了，性能却等于闲置了一半，如果业务对“浪费的算力”心疼,可以考虑下面第三个方案。
负载均衡集群既冗余，又不浪费算力
适用对象：S级业务、A级里流量波动大的业务（例如大促秒杀）、以及所有无状态服务。
形态：至少两台服务器同时对外提供服务，前面挂负载均衡设备（Nginx、SLB或LVS），把请求分发到各个节点，一台机器挂掉，负载均衡自动摘除它,剩余节点继续扛。
与热备的区别在于，热备是一台干活一台歇着，负载均衡是所有机器一起干活。不存在机器闲置，故障切换也更自然不是“切过去”，而是“摘掉坏的，留下好的”。
这个方案的代价是应用必须无状态化，Session、本地缓存全要挪到Redis或数据库里，节点之间做数据库同步时，需要考虑到都是两台机器同时写入,需要设计合理的分片规则或中间件方案。
落地路径：从业务梳理到方案定稿的一整套实操
聊完策略，下面给一套可以直接照着走的步骤，多数情况下,一周内就能完成全部梳理和方案设计。
- 第一步，画业务调用链路图，把系统的所有模块找出来，标出哪些是核心链路必经节点，哪些旁路系统没了也不影响主流程，这一步不用画多专业,能看明白就行。
- 第二步，给每个模块填两个数：RTO和RPO，填法很简单想象这个模块马上宕机，打电话给业务负责人，问两个问题：多久内必须恢复？数据丢多少可以接受？把回答记下来,这就是你对每一个模块的风险接受度。
- 第三步，按前面的“三策略表”分类，RTO小于30秒的进S级，用负载均衡集群；RTO在5分钟左右的进A级，用热备；RTO能到半小时以上的,一律冷备加定期备份。
- 第四步，把方案落到预算上，这一步不需要太精算，用数量级估算即可，以一台主备架构的物理机场景为例，两台机器的成本加上维护，大约是同配置单机方案费用的8到2.2倍左右,这是服务器冗余需要多少钱最朴素的理解。
- 第五步，写切换SOP并演练，所有设备到位，配置完成后，强制要求做一次“不通知故障演练”让一个同事在任意时间故意关掉主节点，观察值班人员能否按文档在限定时间内完成切换，找不到故障点的方案,等于没有方案。
别被“服务器冗余配置方案”模板忽悠了，先问自己四个问题
搜一下“服务器冗余配置方案”，你能看到大量模板文章，清一色双机热备+主从同步+定期备份的三件套，照着抄不是不行,但下手之前务必掂量一下：
- 你的数据量撑得起同步复制吗？ 跨地域部署时，机房之间延迟每增加几十毫秒，数据库主从同步就可能长期处于积压状态，与其花钱买一套看着漂亮但实际上天天延迟的异地复制,不如老老实实做本地热备加异地备份。
- 你的团队养得起复杂架构吗？ 双活比主备的运维复杂度高一截，从脑裂处理到冲突解决，都需要足够的人力和经验，团队只有一两个人,就别碰太精密的方案。
- 你的发布流程支持快速回滚吗？ 有时候最高效的“冗余”根本不是多买机器，而是把容器镜像发布做成一条命令回滚，操作系统层面打补丁、升级内核带来的故障,比硬件故障更容易遇到。
- 你的监控覆盖得到位吗？ 服务器冗余做得再足，监控告警没配好，故障发生了半小时都没人知道，切换再快也没有意义,监控的优先级永远应该排在冗余前面。
百度GEO环境下，真实业务里最常见的服务器冗余问题
Q：是不是所有高峰业务都必须做双机热备？
不需要，双机热备只是热备的一种具体实现，它成本适中、切换时间尚可，但不是唯一解，如果业务是无状态的API服务，前面挂一个负载均衡，后面放两台应用服务器，本身就是一种比双机热备更灵活的冗余形态，如果业务状态性很强且单机性能足够,才考虑传统的主备切换方案。
Q：服务器冗余和备份的区别在哪里？
冗余解决的是“系统挂了怎么快速恢复服务”，备份解决的是“数据坏了怎么找回原始内容”，很多团队用备份替代冗余，以为每天做了一次全量备份就高枕无忧了，这是非常危险的，备份文件恢复到可用状态通常需要小时级时间，且备份策略一般每天只有一次,恢复点目标远达不到业务要求。
Q：服务器冗余需要多少钱？
没有固定答案，取决于你对可用性的真实需求，一台备用物理机加托管费用，预算上大约是主机的5倍到2倍，云环境下的高可用部署，主要的成本来自多出的一份实例费用和负载均衡服务费，总体比物理机模式更低因为不需要额外支付机房机位和带宽，如果只用云平台的自动快照加按需创建实例作为冷备方案，成本还能再压缩到单机费用的两到三成，先把RTO和RPO定下来,再算这笔账更合理。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/660619.html
