1. 需求分析

1.1 应用场景

1. 经典的接口服务（API）访问场景：需要在多台后端服务器之间实现负载均衡，同时通过 Nginx 实现反向代理来对外统一出口
2. 两台进行主负载均衡， 一台作为备用服务器（只有主服务器都不可用时才启用）

1.2 实现目标

1. 多台 API 服务器之间实现请求均衡分发，提高服务并发能力
2. 使用 Nginx 作为统一访问入口，隐藏后端结构
3. 保证接口请求的响应速度和可靠性

2. Nginx反向代理与实现均衡负载

2.1 部署架构

2.2 架构描述

2.2.1 Nginx代理服务器

需要有一个独立的前置 Nginx 服务器，用于接收所有客户端请求并进行反向代理和负载均衡。这个服务器不参与接口服务本身，而是作为网关服务器存在。

（单独一台机器或轻量容器，部署在公网可访问或局域网的前端位置）

2.2.2 API服务器与API服务器（Backup）

部署在内网的三台后端服务器，监听特定端口。其中Backup作为后备服务器，在请求访问主API服务器时启动。

2.2.3 nginx.conf配置文件

Nginx配置示例：

---

http {upstream api_backend {# 主服务器（轮询）server 192.168.1.101:5000 max_fails=3 fail_timeout=30s;server 192.168.1.102:5000 max_fails=3 fail_timeout=30s;# 后备服务器，仅在主服务器全部不可用时启用server 192.168.1.103:5000 backup;}server {listen 80;  # 对外暴露的portserver_name api.example.com;  # 对外暴露的hostlocation / {proxy_pass http://api_backend;# 常规头设置proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;# 连接优化proxy_connect_timeout 5;proxy_send_timeout 30;proxy_read_timeout 30;}}
}

Nginx配置项说明：

---

配置项	说明
upstream api_backend	上游服务器池
max_fails	最大失败次数
fail_timeout	最大失败等待时间
proxy_connect_timeout	连接后端服务器的超时时间（TCP 三次握手时间限制）
proxy_send_timeout	Nginx 向后端服务器发送请求的超时时间
proxy_read_timeout	等待后端服务器响应的最大时间

主服务器轮询机制：

---

• 默认轮询（Round Robin）

  每个请求依次分发给后端服务器，不考虑服务器性能或连接数。

  upstream api_backend {server 192.168.1.101:5000;server 192.168.1.102:5000;
  }
  

• 权重轮询（Weighted Round Robin）

  根据每台服务器的性能分配不同权重，权重越高，请求越多。

  upstream api_backend {server 192.168.1.101:5000 weight=3;server 192.168.1.102:5000 weight=1;
  }
  

• 最少连接数（Least Connections）

  将请求分发给当前连接数最少的服务器。

  upstream api_backend {least_conn;server 192.168.1.101:5000;server 192.168.1.102:5000;
  }
  

• IP 哈希（IP Hash）

  根据客户端 IP 分发请求，同一 IP 总是转发给同一台后端服务器，适合需要会话保持的情况。

  upstream api_backend {ip_hash;server 192.168.1.101:5000;server 192.168.1.102:5000;
  }
  

  注：ip_hash 不支持 backup 参数

算法	特点	适用场景
Round Robin	简单依次转发	默认，性能相近的服务器
Weight	按性能分配负载	部分服务器性能较强
Least Conn	优先连接少的服务器	请求耗时长/负载不均
IP Hash	同 IP 请求同一服务器	需要 Session 保持

后备服务器生效机制（Backup）

---

Nginx 会自动探测主服务器失败（例如连接超时、502、503等），如果全部主节点失败，则自动切换到 backup 节点处理请求。

2.2.4 测试方法

1. 正常访问时，轮询 Server1 和 Server2
2. 停止 Server1 和 Server2，再访问接口，请求会自动落到 Server3
3. 恢复主节点后，访问会自动回归主服务器

3. 高速会话缓存技术

3.1 问题背景

在使用 Nginx 做负载均衡时，请求会被分发到不同的后端服务器，而如果会话（Session）信息保存在单台服务器上，会导致以下问题：

• 登录状态丢失
• 用户需要重复登录
• 无法维持用户上下文信息

3.2 使用 Redis 存储 Session

3.2.1 优势

• 快速、共享、可横向扩展
• 多个后端节点可以访问同一份 Session 数据

3.2.2 部署架构图

3.2.3 后端配置

在 Flask / Django / Spring Boot 等应用中配置：

• 将用户 Session 保存在 Redis 中（而非本地内存）
• 各服务器通过 Redis 获取 Session 数据

Flask示例：

# Flask 示例（使用 Flask-Session）
from flask import Flask, session
from flask_session import Sessionapp = Flask(__name__)
app.config['SESSION_TYPE'] = 'redis'
app.config['SESSION_REDIS'] = redis.Redis(host='localhost', port=6379)
Session(app)