1. 为什么需要Nginx高可用集群？
去年我们电商系统在大促时遭遇了惨痛的教训。当时单台Nginx服务器突然宕机，导致整个网站不可用近20分钟，直接损失订单金额超过七位数。这次事故让我深刻意识到：在关键业务系统中，单点故障就是悬在头上的达摩克利斯剑。
Nginx作为现代Web架构的流量入口，其稳定性直接影响整个系统的可用性。根据行业统计，采用高可用架构可以将系统可用性从99.9%提升到99.99%，这意味着每年故障时间从8.76小时缩短到52.56分钟。对于金融、电商等关键业务场景，这近8小时的差异可能就是生死之别。
2. 集群架构设计解析
2.1 典型双机热备方案
我们最终采用的方案是主从双机+Keepalived的经典组合。这个方案的优势在于：
- 实现简单：仅需2台服务器
- 故障切换快：实测平均切换时间在3秒内
- 资源利用率高：备用机平时可承担部分读流量
架构示意图：
[客户端] | [虚拟IP(VIP)] / \ [Nginx主] [Nginx备] | | [后端服务集群]2.2 Keepalived工作原理
Keepalived通过VRRP协议实现主备选举，关键配置参数包括：
- priority：主节点建议设为100，备节点90
- advert_int：心跳间隔，默认1秒
- authentication：建议启用密码认证
当主节点不可达时，备节点会经历：
- 检测到主节点失联（通常3个心跳周期）
- 发起选举（本地优先级最高则直接接管）
- 绑定VIP到本地网卡
- 发送免费ARP更新路由表
3. 详细配置实战
3.1 基础环境准备
建议使用相同配置的服务器：
- 操作系统：CentOS 7.9
- Nginx版本：1.20.1
- Keepalived版本：2.2.4
网络要求：
- 同一网段内互通
- 禁用防火墙或放行VRRP协议（IP协议号112）
3.2 Nginx安装配置
# 安装EPEL仓库 yum install -y epel-release # 安装Nginx yum install -y nginx # 基础配置建议 worker_processes auto; # 自动匹配CPU核心数 worker_connections 1024; # 每个worker最大连接数 keepalive_timeout 65; gzip on; # 启用压缩3.3 Keepalived配置示例
主节点配置（/etc/keepalived/keepalived.conf）：
global_defs { router_id nginx_master } 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 dev eth0 } }备节点只需修改：
state BACKUP priority 90 router_id nginx_backup3.4 健康检查增强
默认配置只能检测Keepalived进程存活，建议增加Nginx状态检查：
vrrp_script chk_nginx { script "/usr/bin/killall -0 nginx" interval 2 weight -20 } # 在vrrp_instance中添加 track_script { chk_nginx }4. 高级优化方案
4.1 多活架构设计
对于超高并发场景，可以采用DNS轮询+多VIP方案：
[客户端] / \ [VIP1] [VIP2] | | [Nginx1] [Nginx2] \ / [后端服务集群]优势：
- 真正无单点故障
- 支持水平扩展
- 可做灰度发布
4.2 会话保持方案
需要会话保持的应用可采用：
- IP Hash：简单但可能导致负载不均
- Cookie插入：更精确但需要模块支持
upstream backend { ip_hash; server 10.0.0.1; server 10.0.0.2; }4.3 动态扩缩容
结合Consul实现服务自动发现：
upstream backend { consul 10.0.0.1:8500 service=web resolve; }5. 故障排查手册
5.1 常见问题速查
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| VIP不切换 | 防火墙阻断VRRP | 放行IP协议112 |
| 脑裂问题 | 网络分区 | 配置多播检测 |
| 切换延迟 | advert_int设置过大 | 调为1秒 |
| Nginx不工作 | 端口冲突 | netstat -tunlp检查 |
5.2 关键日志位置
- Keepalived日志：/var/log/messages
- Nginx错误日志：/var/log/nginx/error.log
- 网络包捕获：tcpdump -i eth0 vrrp
5.3 压力测试建议
使用wrk模拟故障场景：
wrk -t4 -c1000 -d60s http://VIP/测试时故意kill主节点Nginx，观察：
- 切换时间
- 会话是否保持
- 是否有请求失败
6. 生产环境经验
6.1 监控指标建议
必须监控的关键指标：
- VIP漂移次数
- Nginx活跃连接数
- 5xx错误率
- 上游响应时间
推荐使用Prometheus+Granfa方案：
location /metrics { stub_status on; access_log off; }6.2 版本升级策略
采用蓝绿部署方案：
- 备节点升级验证
- 手动切换VIP
- 原主节点升级
- 根据情况决定是否切回
6.3 性能调优参数
关键内核参数调整：
# 增加端口范围 echo "net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.conf # 提高连接跟踪表大小 echo "net.netfilter.nf_conntrack_max = 655360" >> /etc/sysctl.conf # 生效配置 sysctl -p在Nginx配置中，对于长连接服务建议：
keepalive 100; # 每个worker保持的空闲连接数 keepalive_timeout 300s;这套架构已经在我们的生产环境稳定运行3年，经历了多次大促考验。最关键的体会是：高可用不是一劳永逸的，需要定期进行故障演练，建议至少每季度模拟一次主节点宕机，验证系统的真实容灾能力。
