欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Nginx負(fù)載均衡通用方案詳解

 更新時間:2025年10月10日 09:49:09   作者:zrande  
本文介紹Nginx負(fù)載均衡的最優(yōu)配置方案,強(qiáng)調(diào)了因應(yīng)不同場景(如視頻會議和商城)需求差異的重要性,提出通過模塊化配置和核心組件組合,實現(xiàn)一次配置多場景覆蓋,本文給大家介紹的非常詳細(xì),感興趣的朋友跟隨小編一起看看吧

Nginx 負(fù)載均衡通用方案:一次配置覆蓋視頻會議、商城等場景

很多人會問:“為什么不能用一套策略搞定所有場景?難道要每天改配置?” 其實不是 “不想通用”,而是不同業(yè)務(wù)的核心需求存在本質(zhì)差異 —— 就像給運動員選裝備,跑步要輕量跑鞋,游泳要防水泳衣,“通用裝備” 只會讓所有場景都達(dá)不到最優(yōu)。

但好在場景(視頻會議、商城)有共通的 “穩(wěn)定需求”,我們可以通過 “核心組件組合” 形成 “趨近通用” 的最優(yōu)方案:無需頻繁更新策略,新增節(jié)點僅需加一行配置,既能滿足視頻會議的低延遲、也能適配商城的會話保持均衡。

一、先搞懂:為什么沒有 “絕對通用” 的策略?

兩個場景需求存在 “天然矛盾”,單一策略無法兼顧,舉兩個關(guān)鍵例子:

需求矛盾點視頻會議的要求商城的要求單一策略的缺陷
連接超時時間300s+(避免視頻斷流)60s(避免支付等待過久)設(shè) 300s 會導(dǎo)致商城支付超時,設(shè) 60s 會斷視頻流
會話保持方式同一用戶連同一節(jié)點即可登錄后絕對不能換節(jié)點用 ip_hash會讓 NAT 環(huán)境的視頻用戶擠一塊,用 Cookie 粘滯多余,暫不談

通用方案的邏輯:不追求 “單一策略通吃”,而是用 “模塊化配置”—— 把 “流量分配、會話保持、容錯、緩存” 拆成獨立組件,按場景需求 “按需啟用”,核心策略(如最少連接 + 權(quán)重)固定不變,僅對差異化需求(如超時時間)做局部適配。

二、趨近通用的最優(yōu)方案:核心組件組合

這套方案的核心是 “4個固定組件 + 2個場景適配點”,配置一次后,后續(xù)僅需新增 / 調(diào)整后端節(jié)點,無需改策略邏輯:

核心組件作用(覆蓋所有場景)為什么選它?
最少連接(least_conn)+ 權(quán)重(weight)動態(tài)分配流量:連接少、性能強(qiáng)的節(jié)點多承接請求視頻會議怕單節(jié)點過載,怕 CPU 堆積,商城怕流量不均,這組組合能全解決
后端會話共享(Redis)商城登錄不丟會話,視頻會話穩(wěn)定不用糾結(jié) ip_hash/Cookie 粘滯,所有場景共用一套會話邏輯,后端改一次就行
健康檢查(max_fails/fail_timeout)自動剔除故障節(jié)點,避免服務(wù)中斷不管哪個場景,節(jié)點宕機(jī)都能自動切流量,不用人工干預(yù)
靜態(tài)緩存(proxy_cache)緩存圖標(biāo)、JS、報告模板等靜態(tài)資源減輕所有場景的后端壓力,商城靜態(tài)資源加載更快
場景適配點適配邏輯(僅需配置一次,后續(xù)不變)
超時時間用 location 區(qū)分:視頻會議 300s,商城 60s
靜態(tài)資源路徑統(tǒng)一緩存后綴(.jpg/.js 等)
支付接口保護(hù)支付接口關(guān)閉重試(避免重復(fù)支付)

三、完整通用配置(拿來即用,含后端適配)

3.1. 前置準(zhǔn)備(僅需做一次)

先確保服務(wù)器安裝以下環(huán)境(后續(xù)不用改):

  • Nginx 1.20+(需內(nèi)置ngx_http_upstream_module/ngx_http_proxy_module,默認(rèn)已裝)
  • Redis 6.0+(用于會話共享,建議主從架構(gòu),保障高可用)
  • 后端框架:Java(Spring Boot)/PHP/Python(需支持 Redis 會話,示例用 Spring Boot)

3.2. Nginx 完整配置(覆蓋兩大場景)

# --------------------------
# 1. 定義后端集群(所有場景共用一個upstream,新增節(jié)點僅需加server行)
# --------------------------
upstream universal_servers {
	# 后端節(jié)點配置:weight=性能權(quán)重(8核16G設(shè)3,4核8G設(shè)2,2核4G設(shè)1)
	# max_fails=2:2次請求失敗標(biāo)記故障;fail_timeout=30s:故障后隔離30秒
	server 192.168.1.101:8080 weight=3 max_fails=2 fail_timeout=30s; # 高性能節(jié)點(視頻優(yōu)先用)
	server 192.168.1.102:8080 weight=2 max_fails=2 fail_timeout=30s; # 中性能節(jié)點(商城用)
	server 192.168.1.103:8080 weight=2 max_fails=2 fail_timeout=30s; # 中性能節(jié)點(通用)
	# 固定核心策略:最少連接(動態(tài)分配,避免單節(jié)點過載)+權(quán)重(按性能分配)
	least_conn;
	# 健康檢查:所有場景共用,無需修改
}
# --------------------------
# 2. 靜態(tài)緩存配置(所有場景共用,減輕后端壓力)
# --------------------------
	# 緩存目錄:/var/nginx/cache,10G上限,7天未訪問自動清理
	proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=universal_cache:100m;
	inactive=7d max_size=10g;
# --------------------------
# 3. 前端訪問配置(按域名區(qū)分場景,適配差異化需求)
# --------------------------
# 場景1:視頻會議(meet.yourdomain.com)
server {
	listen 80;
	listen 443 ssl;
	server_name meet.yourdomain.com;
	# HTTPS證書(所有場景共用,替換成你的證書路徑)
	ssl_certificate /etc/nginx/ssl/your_cert.crt;
	ssl_certificate_key /etc/nginx/ssl/your_cert.key;
	ssl_protocols TLSv1.2 TLSv1.3; # 安全協(xié)議固定
	# 視頻會議專屬適配:長連接超時(300s避免斷流)
	proxy_connect_timeout 300s;
	proxy_send_timeout 300s;
	proxy_read_timeout 300s;
	# 視頻流緩沖區(qū)(適配大流量)
	proxy_buffer_size 32k;
	proxy_buffers 4 64k;
	# 傳遞真實IP和會話信息(所有場景共用)
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-Proto $scheme; # 傳遞HTTPS標(biāo)識
	# 視頻會議請求轉(zhuǎn)發(fā)(無靜態(tài)緩存,全走動態(tài))
	location / {
		proxy_pass http://universal_servers;
		# 故障重試:視頻流斷連后自動切節(jié)點(最多2次)
		proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
		proxy_next_upstream_tries 2;
	}
}
# 場景2:商城(mall.yourdomain.com)
server {
	listen 80;
	listen 443 ssl;
	server_name mall.yourdomain.com;
	# 復(fù)用HTTPS證書(不用重復(fù)配置)
	ssl_certificate /etc/nginx/ssl/your_cert.crt;
	ssl_certificate_key /etc/nginx/ssl/your_cert.key;
	ssl_protocols TLSv1.2 TLSv1.3;
	# 商城專屬適配:普通超時(60s避免支付等待)
	proxy_connect_timeout 60s;
	proxy_send_timeout 60s;
	proxy_read_timeout 60s;
	# 傳遞真實IP和會話信息(復(fù)用)
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-Proto $scheme;
	# 商城靜態(tài)資源緩存(圖標(biāo)、JS、CSS,減輕后端壓力)
	location ~* \.(jpg|jpeg|png|gif|js|css|ico)$ {
		proxy_cache universal_cache; # 復(fù)用全局緩存
		proxy_cache_valid 200 304 7d; # 正常響應(yīng)緩存7天
		proxy_cache_valid any 1m; # 異常響應(yīng)緩存1分鐘
		proxy_cache_key $host$uri$is_args$args; # 避免重復(fù)緩存
		proxy_pass http://universal_servers;
		expires 7d; # 瀏覽器本地也緩存
	}
	# 商城支付接口專屬配置:關(guān)閉重試(避免重復(fù)支付)
	location ~ /api/pay/ {
		proxy_pass http://universal_servers;
		proxy_next_upstream off; # 禁止重試,防止多扣費
	}
	# 商城其他請求轉(zhuǎn)發(fā)
	location / {
	proxy_pass http://universal_servers;
	}
}

3.3. 后端適配(僅需做一次,所有場景共用)

核心是Redis 會話共享(解決商城會話不丟,同時讓視頻會話穩(wěn)定),以 Spring Boot 為例(其他框架邏輯類似):

步驟 1:引入依賴(pom.xml)
<!-- Redis會話共享核心依賴 -->
<dependency>
	<groupId>org.springframework.session</groupId>
	<artifactId>spring-session-data-redis</artifactId>
</dependency>
<!-- Redis客戶端 -->
<dependency>
	<groupId>redis.clients</groupId>
	<artifactId>jedis</artifactId>
</dependency>
<!-- Web依賴(確保已引入) -->
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-web</artifactId>
</dependency>
步驟 2:配置 Redis(application.yml)
spring:
	# Redis會話配置(所有場景共用)
	session:
		store-type: redis # 會話存到Redis
		redis:
			namespace: universal:session # 會話key前綴(避免和其他業(yè)務(wù)沖突)
			host: 192.168.1.301 # 你的Redis地址
			port: 6379
			password: your_redis_password # 你的Redis密碼(無密碼可刪)
			timeout: 2000ms # Redis連接超時
	# Redis基礎(chǔ)配置
	redis:
		host: 192.168.1.301
		port: 6379
		password: your_redis_password
		jedis:
			pool:
				max-active: 100 # 最大連接數(shù)(適配高并發(fā))
				max-idle: 20 # 最大空閑連接
步驟 3:啟動類加注解(開啟會話共享)
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.session.data.redis.config.annotation.web.http.EnableRedisHttpSession;
@SpringBootApplication
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 86400) // 會話有效期1天(所有場景通用)
public class UniversalApplication {
	public static void main(String[] args) {
		SpringApplication.run(UniversalApplication.class, args);
	}
}

四、分場景驗證:方案是否真的通用?

不用你手動判斷,按以下步驟驗證,確保每個場景都能正常運行:

4.1. 視頻會議場景(驗證 “不卡頓 + 負(fù)載均衡”)

  • 操作:用 10 臺設(shè)備(同一 NAT 網(wǎng)絡(luò),如公司 WiFi)訪問meet.yourdomain.com,加入不同會議;
  • 驗證 1(負(fù)載均衡):在后端節(jié)點執(zhí)行netstat -an | grep 8080 | grep ESTABLISHED | wc -l,101 節(jié)點(weight=3)連接數(shù)≈102+103 節(jié)點之和(符合權(quán)重比例);
  • 驗證 2(不卡頓):持續(xù)視頻30 分鐘,無斷流;手動停掉 101 節(jié)點,設(shè)備自動切換到 102/103,視頻不中斷。

4.2. 商城場景(驗證 “會話不丟 + 支付安全”)

  • 操作:用瀏覽器訪問mall.yourdomain.com,登錄后加購物車、下單;
  • 驗證 1(會話不丟):手動停掉當(dāng)前連接的節(jié)點(如 102),刷新頁面,購物車、登錄狀態(tài)仍在(Redis 讀取會話);
  • 驗證 2(支付安全):發(fā)起支付請求,故意停掉后端節(jié)點,Nginx 不重試(proxy_next_upstream off),無重復(fù)支付。

五、落地與維護(hù):不用頻繁更新策略

這套方案的核心優(yōu)勢是 “維護(hù)簡單”,你后續(xù)僅需做 3 件事,不用改策略邏輯:

5.1. 新增后端節(jié)點(僅需 1 行配置)

當(dāng)用戶變多,要加新節(jié)點時,只需在upstream universal_servers里加一行:

server 192.168.1.104:8080 weight=2 max_fails=2 fail_timeout=30s; # 新節(jié)點

然后執(zhí)行nginx -t(驗證語法)→nginx -s reload(生效配置),流量會自動按 “最少連接 + 權(quán)重” 分配,不用改其他配置。

5.2. 調(diào)整節(jié)點權(quán)重(僅改數(shù)字)

若某節(jié)點性能升級(如 102 節(jié)點從 4 核升到 8 核),只需把weight=2改成weight=3,重啟 Nginx 即可,策略邏輯不變。

5.3. 監(jiān)控(確保穩(wěn)定,不用手動盯)

裝一套Prometheus+Grafana(有現(xiàn)成腳本一鍵部署),監(jiān)控 3 個指標(biāo):

  • Nginx 連接數(shù):訪問/nginx_status(需在 Nginx 配置里啟用stub_status模塊);
  • 后端節(jié)點 CPU / 內(nèi)存:監(jiān)控192.168.1.101等節(jié)點的資源;
  • Redis 會話數(shù):執(zhí)行redis-cli keys "universal:session:*" | wc -l,避免會話堆積。

六、總結(jié):為什么這是最優(yōu)方案?

對比維度這套通用方案市面零散方案
策略挑選不用選,一次配置覆蓋多個場景需按場景選 ip_hash/least_conn/sticky,易出錯
維護(hù)成本新增節(jié)點僅加 1 行,不用改策略加節(jié)點要重新評估策略,可能改多處配置
場景適配內(nèi)置視頻 / 商城的差異化適配需手動改超時、緩存等參數(shù),易遺漏
穩(wěn)定性Redis 會話 + 健康檢查,容錯性強(qiáng)單策略容錯弱(如 ip_hash 在 NAT 下過載)

簡單說:你把這份配置復(fù)制到服務(wù)器,按步驟適配后端,后續(xù)只需加節(jié)點、調(diào)權(quán)重,不用再糾結(jié) “選什么策略”—— 這套方案已經(jīng)幫你把最優(yōu)邏輯固定好了。

附:必備工具與腳本(直接用)

  1. Nginx 狀態(tài)模塊啟用(監(jiān)控連接數(shù)):
location /nginx_status {
	stub_status on;
	allow 192.168.1.0/24; # 僅允許內(nèi)網(wǎng)訪問
	deny all;
}
  1. Redis 會話清理腳本(避免過期會話堆積,加進(jìn)定時任務(wù)):
#!/bin/bash
redis-cli -h 192.168.1.301 -a your_redis_password KEYS "universal:session:*" | xargs redis-cli DEL
  1. Nginx 配置備份腳本(改配置前執(zhí)行):
#!/bin/bash
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf_$(date +%Y%m%d)

到此這篇關(guān)于Nginx 負(fù)載均衡通用方案的文章就介紹到這了,更多相關(guān)nginx 負(fù)載均衡內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • 制作nginx的RPM包教程

    制作nginx的RPM包教程

    這篇文章主要介紹了制作nginx的RPM包的方法,需要的朋友可以參考下
    2014-07-07
  • 一句簡單命令重啟nginx

    一句簡單命令重啟nginx

    最近我的多個VPS經(jīng)常出現(xiàn)502錯誤,經(jīng)常需要重啟nginx,但網(wǎng)上的很多教程都需要繁瑣的啟動腳本,遠(yuǎn)不如apache的重啟命令那么簡單。
    2010-03-03
  • nginx中使用nginx-http-concat模塊合并靜態(tài)資源文件

    nginx中使用nginx-http-concat模塊合并靜態(tài)資源文件

    這篇文章主要介紹了nginx中使用nginx-http-concat模塊合并靜態(tài)資源文件,用以加速網(wǎng)站的CSS、JS等靜態(tài)資源載入速度,需要的朋友可以參考下
    2014-06-06
  • 詳解如何在Nginx中設(shè)置文件上傳大小限制

    詳解如何在Nginx中設(shè)置文件上傳大小限制

    在使用 Nginx 進(jìn)行文件上傳時,我們可能需要對上傳文件的大小進(jìn)行限制,以防止用戶上傳過大的文件導(dǎo)致服務(wù)器負(fù)載過高,本文將介紹如何在 Nginx 中設(shè)置文件上傳大小限制,需要的朋友可以參考下
    2023-07-07
  • 解決nginx 503 Service Temporarily Unavailable方法示例

    解決nginx 503 Service Temporarily Unavailable方法示例

    這篇文章主要介紹了解決nginx 503 Service Temporarily Unavailable方法示例,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2019-12-12
  • 如何用Nginx解決前端跨域問題

    如何用Nginx解決前端跨域問題

    在開發(fā)靜態(tài)頁面時,類似Vue的應(yīng)用,我們常會調(diào)用一些接口,這些接口極可能是跨域,這篇文章主要介紹了如何用Nginx解決前端跨域問題,非常具有實用價值,需要的朋友可以參考下
    2019-01-01
  • Nginx中透傳客戶端真實IP的技巧

    Nginx中透傳客戶端真實IP的技巧

    為了記錄日志、限制訪問或進(jìn)行其他基于?IP?地址的操作,獲取客戶端的真實?IP?地址非常重要,本文就來詳細(xì)的介紹一下Nginx中透傳客戶端真實IP的技巧,感興趣的可以了解一下
    2024-08-08
  • 阿里云國際版使用Nginx作為HTTPS轉(zhuǎn)發(fā)代理服務(wù)器的處理方法

    阿里云國際版使用Nginx作為HTTPS轉(zhuǎn)發(fā)代理服務(wù)器的處理方法

    本文介紹了使用NGINX作為HTTPS流量轉(zhuǎn)發(fā)代理的兩種方法。它總結(jié)了NGINX使用HTTP?CONNECT隧道和NGINX流充當(dāng)HTTPS轉(zhuǎn)發(fā)代理的解決方案的原則,環(huán)境構(gòu)建要求,應(yīng)用場景和關(guān)鍵問題
    2022-05-05
  • Nginx?Socket代理的實現(xiàn)方法

    Nginx?Socket代理的實現(xiàn)方法

    Nginx的socket代理通常指的是Nginx通過stream模塊來處理非HTTP的?TCP?流量,本文就來介紹一下Nginx?Socket代理的實現(xiàn)方法,具有一定的參考價值,感興趣的可以了解一下
    2024-04-04
  • Nginx設(shè)置wordpress偽靜態(tài)的方法示例

    Nginx設(shè)置wordpress偽靜態(tài)的方法示例

    偽靜態(tài)是相對真實靜態(tài)來講的,通常我們?yōu)榱嗽鰪?qiáng)搜索引擎的友好面,這篇文章主要介紹了Nginx設(shè)置wordpress偽靜態(tài)的方法示例,非常具有實用價值,需要的朋友可以參考下
    2018-09-09

最新評論