千万级并发架构实战：四层负载 + 高可用 +七层负载！

千万级负载并发架构

在千万级高并发、超大流量的互联网架构中，单点的 Nginx 已经无法承载巨大的网络吞吐和连接数。

因此，业界演进出了经典的黄金组合：LVS + Keepalived + Nginx（四层负载 + 高可用 + 七层负载与反向代理）。

[ 客户端 Client ]
       │
       ▼ (DNS / VIP)
+-----------------------+
| Keepalived + LVS (Master) |  <--- 四层负载（工作在 OS 内核态，只做 IP/Port 转发，极致吞吐）
+-----------------------+
       │  (DR 模式直连)
       ▼
+-----------------------+
|  Nginx 集群 (多节点)    |  <--- 七层负载（工作在用户态，做 SSL 终结、URL 路由、限流、缓存）
+-----------------------+
       │
       ▼
+-----------------------+
|  后端应用集群 (Java/Go) |  <--- 业务服务
+-----------------------+

LVS、Nginx 与 Keepalived 常被组合使用；

LVS：负责高性能四层负载均衡；

Nginx：承担七层代理与应用流量治理；

Keepalived：则用于保障关键节点的高可用。

 

LVS

LVS 通常部署在最前端，以 DR 模式将请求分发到多台 Nginx。

为什么LVS 要部署在最前端？为什么能扛千万级？

原因是：LVS 是集成在 Linux 内核（IPVS）中的模块。

它不解析 HTTP 协议，不维护复杂的应用状态，仅仅修改数据包的目标 MAC 地址或 IP 地址。

# 开启 IP 转发
net.ipv4.ip_forward = 1

# 增大连接队列
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# 快速回收 TIME_WAIT，需结合业务谨慎评估
net.ipv4.tcp_tw_reuse = 1

# 扩大端口范围
net.ipv4.ip_local_port_range = 1024 65000

它的 CPU 消耗极低，LVS（配合万兆网卡）轻松支撑百万甚至千万级 QPS。

常见的转发模式包括：NAT、DR和TUN。

其中DR模式因响应流量可直接由后端服务器返回，常用于对吞吐量要求较高的场景，但需要后端网络配置配合。

 

Nginx

Nginx工作在应用层，能够识别HTTP请求，并据此进行反向代理、负载均衡、TLS终止、静态资源处理、访问控制和限流。

worker_processes auto;               # 与 CPU 核心数对齐
worker_rlimit_nofile 655350;         # 进程最大文件句柄数

events {
    worker_connections 65535;        # 单个进程最大连接数
    use epoll;                       # 使用 Linux 高性能事件驱动模型
    multi_accept on;
}

http {
    # 开启高效文件传输模式
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # 连接超时优化
    keepalive_timeout 65;
    keepalive_requests 10000;

    # 开启长连接池给后端
    upstream backend_cluster {
        server 192.168.1.10:8080 max_fails=3 fail_timeout=10s;
        server 192.168.1.11:8080 max_fails=3 fail_timeout=10s;
        keepalive 300;               # 维持与后端的高速长连接池
    }
}

它适合处理需要理解业务协议、路径或请求头的流量，也可以通过缓存、连接复用等方式降低后端压力。

 

Keepalived

Keepalived基于VRRP提供虚拟路由冗余能力，常用于在多台负载均衡节点之间维护虚拟IP。

vrrp_script check_haproxy {
    script "/usr/bin/killall -0 lvs" # 检查 LVS/Nginx 进程状态
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 123456
    }
    virtual_ipaddress {
        192.168.1.100/24 # 对外对外暴露的 VIP
    }
    track_script {
        check_haproxy
    }
}

当主节点故障时，备用节点接管虚拟IP，从而减少入口中断时间。

需要注意的是，Keepalived解决的是节点或链路层面的故障切换问题，并不自动保证应用服务正确，也不能替代完善的健康检查和故障演练。

以上