高可用方案怎么选？别光看参数，先想清楚这三件事

公司官网突然打不开，客服系统卡在登录页，订单接口半天没响应——这类故障背后，十有八九是高可用设计没到位。但一说“上高可用”，很多人第一反应就是堆硬件、买负载均衡、上双机热备，结果钱花了，问题照旧。

先问自己：你到底怕什么？

不是所有系统都需要“99.999%可用性”。电商大促期间的下单服务，宕机5分钟可能损失几十万；而内部用的文档共享系统，停两小时，大家喝杯咖啡等一等也无妨。选型前得拎清：你的业务容忍几秒中断？能接受多大程度的数据延迟？故障时要不要自动回切？

常见组合，其实就那几类

中小团队最常遇到的，其实是三类典型场景：

场景1：Web服务单点瓶颈
比如用一台Nginx反向代理后端PHP服务，机器一挂全站瘫痪。这时最实在的方案是：两台Nginx + Keepalived 做主备VIP漂移，后端PHP服务本身用短连接+健康检查，不强求状态同步。配置简单，故障切换3秒内完成，成本不到万元。

场景2：数据库写单点
MySQL主从复制很常见，但很多只配了读从库，写还是死磕主库。真出问题，手动切主从又慢又容易丢数据。建议直接上MHA（Master High Availability）或更轻量的Orchestrator，能自动探测主库宕机、提升从库、重置复制链路，整个过程20秒内搞定。

场景3：微服务跨机房容灾
比如用户中心部署在上海，订单服务在杭州，两地专线偶尔抖动。这时候硬搞“两地三中心”反而增加复杂度。不如用服务注册中心（如Nacos）加权重路由：平时90%流量走本地，专线异常时自动降级到另一地，再配合异步消息补偿关键操作，实际效果比盲目堆集群更稳。

别踩这些坑

• 别迷信“全自动切换”：ZooKeeper集群自己挂了，谁来仲裁？监控和告警必须独立于被监控系统。
• 别忽略应用层适配：后端服务没做连接池重连、没处理事务中间态，再好的基础设施也白搭。
• 别把“高可用”当免死金牌：某公司上了K8s多副本+Service自动发现，结果所有Pod共用一个未做限流的Redis连接池，一崩全崩。

## 示例：Keepalived基础主备配置片段（/etc/keepalived/keepalived.conf）
! Configuration File for keepalived
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
}

高可用不是买来的，是算出来的、测出来的、调出来的。上线前，至少要亲手拔过一次网线、杀过一次进程、断过一次数据库连接——真刀真枪试过，心里才有底。