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)