高可用靠冗余和故障转移，负载均衡靠流量分发，两者配合才能让服务器集群扛住故障和并发冲击
服务器群集配置实现高可用与负载均衡，核心思路是让集群里的每台服务器都能随时接替对方的活，同时把进来的流量按规则分给最闲的那台。听起来不复杂，但真正落地时牵扯到健康检查、会话保持、脑裂防护、VIP漂移这些细节，下面从原理、方案到实操配置一步步拆开说。
高可用负载均衡的核心机制拆解
高可用和负载均衡是两套逻辑，但经常一起部署，高可用解决的是"别挂"的问题，负载均衡解决的是"别挤"的问题，两者的共同点是都需要一个"调度者"来判断哪台机器还活着、哪台机器该接新请求。
VIP漂移是故障切换的基本动作
集群里通常配一个虚拟IP（VIP），客户端只认这个IP，每台后端服务器跑一个Keepalived或Heartbeat之类的软件，互相通过心跳报文探测对方状态，正常情况下VIP绑定在主节点上，主节点挂了，备用节点通过选举机制接管VIP，这个动作行话叫"VIP漂移"，整个过程通常在几秒到几十秒内完成,客户端无感知。
健康检查决定流量往哪走
光有VIP漂移还不够，负载均衡器得知道每台真实服务器的健康状态,常见检查方式有三种：
- TCP端口探测：检查80、443端口是否还监听
- HTTP请求检查：主动请求一个固定URL，看返回码是否为200
- 自定义脚本检查：更精细，能检查数据库连接池、磁盘占用等
行业共识认为，HTTP检查比端口检查更可靠，因为端口通不代表应用没卡死，推荐生产环境至少用HTTP级别的检查，检查间隔设在3到5秒之间,连续失败两次就摘除节点。
会话保持是个容易被忽略的坑
很多应用把登录状态存在服务器本地Session里，负载均衡把请求分散到不同机器后用户就掉线了,解决办法有三个层级：
- 最简单：负载均衡器开启源IP哈希，同一个IP永远分到同一台机器
- 更稳妥：把Session集中存到Redis或Memcached，所有机器共享
- 最彻底：改造应用为无状态设计，JWT方案，Session相关配置项全部从代码里消除
服务器集群高可用负载均衡方案对比
市面上主流的开源方案有三个：LVS、Nginx和HAProxy,选哪个取决于你的业务场景和团队运维能力。
| 方案 | 工作层级 | 性能上限 | 适用场景 | 运维难度 |
|---|---|---|---|---|
| LVS | 四层（传输层） | 极高，单机可扛百万并发 | 大型网站入口，数据库读写分离 | 高，配置复杂，依赖Keepalived配合 |
| Nginx | 七层（应用层） | 中高，单机约几万并发 | Web应用、反向代理、动静分离 | 中，配置灵活，生态成熟 |
| HAProxy | 四层+七层 | 高，介于两者之间 | 需要精细调度策略的场景 | 中，配置直观，自带健康检查和状态页 |
中小企业服务器集群怎么做高可用
对大部分中小团队来说，Nginx+Keepalived是最务实的起点，Nginx做七层负载均衡，Keepalived负责VIP漂移，好处是技术栈统一，排错链路短，等业务量上来了再逐步引入LVS做入口层,Nginx下沉为七层网关。
具体配置步骤大致如下：
第一步：装Keepalived，主备节点都装
yum install keepalived -y
第二步：主节点配置VIP
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.1.100
}
}
备节点把state改成BACKUP、优先级改成100，其他一致，这步配置稍有不慎就会出问题，比如virtual_router_id不一致会导致两个节点抢VIP。
第三步：在Nginx里配置upstream
upstream backend {
server 192.168.1.11:8080 max_fails=2 fail_timeout=30s;
server 192.168.1.12:8080 max_fails=2 fail_timeout=30s;
server 192.168.1.13:8080 max_fails=2 fail_timeout=30s;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
这套配置里，Nginx自身通过max_fails和fail_timeout做被动健康检查，如果想更精细，可以配nginx_upstream_check_module模块实现主动探测。
企业服务器集群配置价格怎么算
预算问题经常被问到。服务器集群配置价格怎么算其实分三块：硬件成本、带宽费用、运维人力。
- 硬件方面，三台2U机架式服务器做基础集群，每台2颗CPU、64GB内存、2块SSD组RAID1，单台合计约8000到15000元
- 带宽按峰值算，杭州机房10M独享带宽年费大概6000到10000元
- 人力成本最不可控，如果没人懂Keepalived和Nginx调优，后续故障处理费用远高于省下的硬件钱
近两年云厂商的托管集群服务也在普及，按量付费模式下每月2000到4000元能跑起一套入门级高可用集群，自建还是上云，需要算总账,不能只看单台机器单价。
从架构层面提升容灾能力
负载均衡和高可用不是配完Keepalived就完事,架构上还有几个关键设计决定灾难发生时的表现。
避免单点：多活才是真高可用
主备模式有个天然缺陷平时备用节点是闲着的，硬件投资回报率低。双活甚至多活架构才是更优解，两台Nginx同时挂VIP后做等价路由，或者用DNS轮询把流量引导到两个机房，这要求应用层架构先支持多活,数据库也要从主从升级为双主或多副本。
流量突发时的自动伸缩能力
基于虚拟机的集群做扩容，步骤繁琐：打镜像、等启动、挂负载均衡、跑健康检查，容器化之后这个流程被压缩到秒级，Kubernetes里的HPA（Horizontal Pod Autoscaler）能根据CPU使用率或自定义指标自动加Pod，配合Ingress Controller做流量入口，相当于把高可用和负载均衡下沉到了编排层，这种方案目前被广泛验证,在电商大促等典型的高并发场景中表现出色。
存储层的可用性同样关键
很多人只关注计算节点，忽略了存储，NFS共享存储挂掉，整个集群都得瘫痪，存储层面至少要做到双控制器+多副本，技术选型上，GlusterFS、Ceph、DRBD都是常用方案，DRBD的玩法是把主节点的块设备实时同步到备节点，配合Pacemaker实现故障切换，典型架构是"两台服务器+DRBD+OCFS2"。
故障场景与排查路径
写点实战经验，下面这些故障,多数运维都遇到过。
VIP漂移了但业务还是不通
最典型的原因是ARP缓存没更新，VIP飘到备机后，交换机还在把流量往原端口送，解决办法是在Keepalived的notify_master脚本里执行：
arping -I eth0 -c 5 -s 192.168.1.100 192.168.1.1
这条命令强制广播更新ARP表，部分云环境下需要配合关闭源/目的IP检查才能生效。
有一台机器老是莫名被摘除
检查健康检查的URL是不是太耗资源，有个客户给Nginx配了/status作为探活地址，结果这个接口本身要查一次数据库，数据库慢查询一多，后端就扛不住探活请求，被误判为宕机，把探活路径改成静态页面,问题立刻消失。
集群脑裂
脑裂是Keepalived最坑的现象两台机器同时持有VIP，都认为自己还活着,排查思路顺藤摸瓜：
- 先看心跳网络是否中断，ping对端内网IP看丢包率
- 检查
advert_int间隔是否太小，默认1秒，网络抖动大时可以调到2秒 - 确认
iptables是否禁用了心跳端口（默认是用vrrp协议，组播地址224.0.0.18） - 应急处理时手动在备节点停掉Keepalived，先保服务恢复，再查根因
高可用负载均衡常见问题解答
做高可用集群，两台服务器够不够用
两台能实现主备高可用，但存在脑裂风险，而且备机在平时不承载流量，生产环境建议至少三台，组成奇数节点，配合Pacemaker/Corosync等集群资源管理器，通过投票机制选举leader，稳定性显著提升，统计下来，三节点集群的实际可用性比两节点高出一个数量级。
负载均衡层本身挂了怎么办
多级负载均衡架构是标准解法，前端用DNS解析到两个机房IP，每个机房内部再部署多台负载均衡器组成集群，如果预算不足，退一步用单台负载均衡器+云平台自动重启策略兜底，近年来的实践表明,云平台自带的健康检查和自动重启机制能将故障恢复时间压缩到分钟级。
Nginx和LVS怎么选型
业务流量在每秒几千到几万这个量级的场景，优先选Nginx，配置灵活、排错容易，流量达到每秒十万以上，或者背后是数据库、Redis这类非HTTP协议的服务，选LVS，LVS的四层转发性能碾压七层代理，但无法感知业务逻辑，两种方案可以结合：LVS做入口，Nginx做后端负载均衡，在北京某中大型电商平台的压测数据中，这种分层组合能把系统吞吐量提升到单层方案的5倍左右。
高可用的本质是消除单点，负载均衡的本质是分摊压力，先把Keepalived配稳，把Nginx的upstream调优，再逐步往容器化和多活架构演进，这是大部分团队都能走通的路径，一步到位的架构不存在的,从业务实际需求出发逐个问题击破才是正道。