去年冬天一家做电商的客户找到我们，说他们的核心订单系统做了双机热备，结果主库宕机的那天，备机切换花了将近八分钟，期间全部下单请求超时，损失了一天的流水。客户很困惑：明明花了钱做高可用，怎么关键时刻还是掉链子？
双机热备的三个常见坑
第一个坑是脑裂问题。两台服务器之间用心跳线检测对方存活，一旦心跳线本身出故障，备机以为主机挂了就发起切换，主机其实还活着，两个实例同时写同一个存储，数据直接打架。这种情况在网口松动或交换机重启时特别容易触发。
第二个坑是共享存储单点。双机热备只保护了计算节点，但两台机器读写的是同一套磁盘阵列。磁盘阵列一旦故障，两台服务器同时失去数据访问能力，高可用形同虚设。
第三个坑是切换时间被低估。很多团队测试时只在业务低峰期做切换演练，实测切换只要一两分钟。但真实故障往往发生在业务高峰期，此时连接池堆积、事务回滚、缓存预热都会拉长恢复时间，实际切换可能远超预期。
怎么把高可用做扎实
第一，心跳检测不要只走一条链路。建议至少配置两条独立的心跳路径，比如一条走业务网络、一条走直连网线或串口线。任意一条心跳中断时不要立刻切换，而是进入仲裁流程，由第三方节点或仲裁磁盘来决定谁该接管服务。
第二，存储层也要做冗余。如果预算允许，把共享存储换成分布式存储或者主从复制架构，避免磁盘阵列成为单点。预算紧张的话，至少给磁盘阵列配上RAID 10和热备盘，缩短磁盘故障的恢复窗口。
第三，定期在业务高峰期做故障切换演练。记录从故障发生到服务恢复的完整时间线，包括检测延迟、切换执行时间、应用重连时间、缓存预热时间。每个环节都有优化空间，比如缩短检测间隔、配置应用层自动重连、提前预热缓存等。
一个判断标准
评估你的高可用方案是否靠谱，看一个问题就够了：如果把主节点现在直接拔电源，业务在多久内恢复？如果回答不上来或者超过五分钟，说明方案还有漏洞，需要尽快补上。高可用架构的价值不在于平时跑得多稳，而在于故障发生时能不能快速恢复服务。