反向代理负载均衡实战：我是如何用 Nginx 搞定高并发流量的

大家好，今天想和大家分享一个我在实际项目中遇到的真实案例——如何通过配置多个反向代理实现负载均衡。这个方案最终帮我们扛住了日均百万级的请求量，过程中踩了不少坑，也积累了一些实用经验。

为什么我们需要多个反向代理？

去年我们接手了一个电商项目，最初架构很简单：单台 Nginx 做反向代理，后面接三台应用服务器。但随着促销活动流量暴涨，Nginx 服务器 CPU 经常跑到 90% 以上，成了新的瓶颈。

这时候我才意识到：反向代理本身也会成为单点故障。于是我们决定部署多个 Nginx 实例，形成代理集群。这里分享下我们的具体实现方案。

基础架构设计

我们最终采用的架构是这样的：

• 2台 Nginx 作为一级代理（暴露在公网）
• 3台 Nginx 作为二级代理（内网）
• 8台应用服务器

这个设计的关键点在于：一级代理只做最基础的请求转发，二级代理才处理复杂的路由规则和缓存。这样既分散了压力，又保持了配置的灵活性。

Nginx 配置详解

一级代理的配置相对简单，主要使用轮询策略：

upstream backend {
    server 192.168.1.101:80;
    server 192.168.1.102:80;
    server 192.168.1.103:80;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

二级代理的配置就复杂多了，我们加入了健康检查、缓存和特定的路由规则：

upstream app_servers {
    least_conn;
    server 10.0.1.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.2:8080 max_fails=3 fail_timeout=30s;
    # ...其他服务器
    keepalive 32;
}

server {
    proxy_cache my_cache;
    proxy_cache_valid 200 302 10m;
    
    location /api/ {
        proxy_pass http://app_servers;
    }
    
    location /static/ {
        proxy_pass http://cdn_servers;
    }
}

踩过的坑和解决方案

在实际部署中，我们遇到了几个典型问题：

1. 会话保持问题：用户登录状态丢失。解决方案是在二级代理配置 sticky session
2. 健康检查误判：网络抖动导致误判服务器下线。调整了 fail_timeout 和 max_fails 参数
3. 代理层缓存不一致：最后我们引入了 Redis 作为共享缓存

监控和调优建议

根据我们的经验，部署后一定要关注这些指标：

• 各层 Nginx 的 active connections
• 请求处理时间（特别是 upstream_response_time）
• 缓存命中率

我们使用 Grafana 搭建了监控看板，当 active connections 超过服务器核心数的 5 倍时就会触发告警。

写在最后

这套架构上线后，最明显的变化是 CPU 负载从 90% 降到了 30% 左右。更重要的是，再也不用担心单点故障导致整个系统瘫痪了。

如果你也在考虑类似方案，我的建议是：先从简单的双节点开始，逐步扩展。毕竟，没有最好的架构，只有最适合的架构。

大家有什么问题或经验分享，欢迎在评论区交流！