網(wǎng)站首頁 編程語言 正文
負(fù)載均衡介紹
什么是負(fù)載均衡
負(fù)載均衡(Load Balance),意思是將負(fù)載(工作任務(wù),訪問請求)進(jìn)行平衡、分?jǐn)偟蕉鄠€(gè)操作單元(服務(wù)器,組件)上進(jìn)行執(zhí)行。
為什么需要負(fù)載均衡
當(dāng)單臺web服務(wù)器直接面向用戶,可能要承載著大量的并發(fā)請求,單臺服務(wù)器可能難以負(fù)荷,我們需要使用多臺web服務(wù)器組成一個(gè)集群,利用Nginx負(fù)載均衡功能,將請求分發(fā)給不同的后端服務(wù)器,實(shí)現(xiàn)負(fù)載的流量分發(fā),提升整體性能、以及系統(tǒng)的容災(zāi)能力。
- 負(fù)載均衡與代理有什么區(qū)別
代理是代理一臺服務(wù)器基于URI調(diào)度,調(diào)度到不同功能的應(yīng)用節(jié)點(diǎn)
負(fù)載均衡是將客戶端請求通過proxy_pass代理至一組upstream資源池
- 實(shí)現(xiàn)負(fù)載均衡場景
實(shí)現(xiàn)負(fù)載均衡功能需要使用兩個(gè)模塊:
- proxy_pass:代理模塊
- upstream:虛擬資源池
示例:一個(gè)官方的的負(fù)載均衡展示
upstream backend {
? ? server backend1.example.com ? ? ? weight=5;
? ? server backend2.example.com:8080;
? ? server unix:/tmp/backend3;
? ? server backup1.example.com:8080 ? backup;
? ? server backup2.example.com:8080 ? backup;
}
server {
? ? location / {
? ? ? ? proxy_pass http://backend;
? ? }
}
示例:自己完成一個(gè)小例子
upstream node {
server 192.168.10.3:80;
server 192.168.10.4:80;
}
server {
listen 80;
server_name www.yyang.com;
location / {
proxy_pass http://node;
include prxoy_params;
}
}
負(fù)載均衡調(diào)度算法
輪詢調(diào)度
按順序逐一分配到不同的后端節(jié)點(diǎn),也是默認(rèn)算法。(簡單來說就是1:1:1)
加權(quán)輪詢
考慮到不同服務(wù)器的性能不同,給予節(jié)點(diǎn)不同的權(quán)值,使其接收到相應(yīng)的權(quán)值請求數(shù)
server 192.168.10.3:80 weight=3;
server 192.168.10.4:80 weight=1;
以上這個(gè)例子是說每4個(gè)請求會(huì)分配給10.3三個(gè),10.4一個(gè),以此循環(huán)。
ip_hash
根據(jù)用戶請求的IP,對該IP進(jìn)行hash運(yùn)算,根據(jù)運(yùn)算的值將請求分配給后端特定的一臺節(jié)點(diǎn)進(jìn)行處理。
取值范圍為ipv4地址的前三個(gè)8位或ipv6的整個(gè)地址作為哈希鍵,確保來自從一個(gè)客戶端的IP始終傳遞給同一臺服務(wù)器,除非次服務(wù)器不可用。(簡單來說就是172.16.20.1與172.16.20.2取前三個(gè)8位都是172.16.20)
ip_hash運(yùn)算公式:hash(ip)%node_counts=index
ip_hash帶來的問題:
大量同一IP的請求會(huì)造成某個(gè)節(jié)點(diǎn)流量過大
如果臨時(shí)下線一臺節(jié)點(diǎn),會(huì)重新計(jì)算hash值,建議使用down狀態(tài)
示例:注意ip_hash與權(quán)重不可同時(shí)使用
ip_hash;
server 192.168.10.3:80;
server 192.168.10.4:80;
一致性hash
為了避免上述問題,所以誕生了一致性hash,使用取模的方式,但不對服務(wù)器節(jié)點(diǎn)數(shù)量取模,而是對2的32次方取模,hash函數(shù)值為0~2^32-1。(形成一個(gè)虛擬圓環(huán),用戶請求會(huì)發(fā)給順時(shí)針相鄰的節(jié)點(diǎn))
有一個(gè)問題:如果后端節(jié)點(diǎn)較少可能會(huì)造成數(shù)據(jù)傾斜,所以一致性hash引入了虛擬節(jié)點(diǎn)機(jī)制,即對每個(gè)服務(wù)器計(jì)算多個(gè)哈希,每個(gè)計(jì)算結(jié)果位置都放置一個(gè)虛擬節(jié)點(diǎn)。
如果我們想使用ip_hash,但是計(jì)算公式使用一致性hash,該怎么做?
hash $remote_addr consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;
url_hash
根據(jù)用戶的url進(jìn)行hash取模,根據(jù)運(yùn)算值,將請求分配給一臺特定的后端服務(wù)器。clent——nginx——url_hash——cache1——app
1.用戶請求nginx負(fù)載均衡,通過url算法,請求調(diào)度至cache1
2.cache1沒有數(shù)據(jù),會(huì)向后端獲取,返回?cái)?shù)據(jù),并將數(shù)據(jù)緩存
3.當(dāng)其他用戶訪問相同url時(shí),調(diào)度器依然會(huì)調(diào)度到cache1節(jié)點(diǎn)
4.cache1會(huì)直接將數(shù)據(jù)返回
hash $request_uri consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;
least_conn
哪臺服務(wù)器的連接數(shù)最少,就將請求調(diào)度到這臺服務(wù)器
least_conn;
server 192.168.10.3:80;
server 192.168.10.4:80;
負(fù)載均衡后端節(jié)點(diǎn)狀態(tài)
down
將服務(wù)器節(jié)點(diǎn)標(biāo)記為不可用狀態(tài),一般用于停機(jī)維護(hù)。
server 192.168.10.3:80 down;
server 192.168.10.4:80;
backup
備用節(jié)點(diǎn),正常情況不會(huì)調(diào)度到此節(jié)點(diǎn);當(dāng)正常工作節(jié)點(diǎn)全部不可用時(shí),會(huì)啟用此節(jié)點(diǎn);當(dāng)節(jié)點(diǎn)恢復(fù)時(shí)此節(jié)點(diǎn)會(huì)繼續(xù)恢復(fù)備用狀態(tài)。
server 192.168.10.3:80;
server 192.168.10.4:80;
server 192.168.10.5:80 backup;
max_conns
用來限制每個(gè)后端節(jié)點(diǎn)接收到的最大的TCP連接數(shù),如果超出限制就會(huì)拋出錯(cuò)誤。
server 192.168.10.3:80 max_conns=10;
server 192.168.10.4:80 max_conns=10;
一臺可以連接10.兩臺是20,超過20就會(huì)出錯(cuò)。
keepalived
與后端服務(wù)器激活緩存,也就是長鏈接,提升網(wǎng)站吞吐量。
默認(rèn)不啟用此功能,當(dāng)有請求時(shí),會(huì)建立連接,維護(hù)連接,關(guān)閉連接,所以會(huì)存在網(wǎng)絡(luò)消耗;但是如果所有連接都緩存了,當(dāng)連接空閑了又會(huì)占用其他系統(tǒng)資源,所以可以使用keepalived參數(shù)。
server 192.168.10.3:80;
server 192.168.10.4:80;
keepalived 32; ? # 最大空閑連接數(shù)的個(gè)數(shù)
keepalived_timeout 100s; # 空閑連接的超時(shí)時(shí)間
# 需要配合以下兩個(gè)參數(shù)使用
proxy_http_version 1.1;
proxy_set_header connection "";
max_fails與fail_timeout
max_fails=2:服務(wù)器通信失敗兩次,認(rèn)為服務(wù)器不可用
fail_timeout=5s:服務(wù)器通信失敗后,每5秒探測一次服務(wù)器是否恢復(fù)正常。
在fail_timeout設(shè)定時(shí)間內(nèi),與服務(wù)器連接失敗次數(shù)達(dá)到max_fails數(shù)量,則認(rèn)為服務(wù)器不可用。
如果不設(shè)置的話默認(rèn)是探測一次,間隔10s。
server 192.168.10.3:80 max_fails=2 fail_timeout=5s;
server 192.168.10.4:80 max_fails=2 fail_timeout=5s;
這部分就到這,其他內(nèi)容放在之后。
原文鏈接:https://blog.csdn.net/qq_42527269/article/details/126079864
相關(guān)推薦
- 2022-11-19 如何使用?Go?和?Excelize?構(gòu)建電子表格_Golang
- 2022-02-22 用Go+Redis實(shí)現(xiàn)分布式鎖的示例代碼_Golang
- 2022-10-22 Android?Choreographer源碼詳細(xì)分析_Android
- 2022-12-02 docker進(jìn)階教程之dockerfile優(yōu)化鏡像大小_docker
- 2023-07-15 express 連接 MongoDb
- 2022-11-01 Git操作規(guī)范之tag的使用技巧詳解_相關(guān)技巧
- 2022-07-17 代碼解析python標(biāo)準(zhǔn)庫logging模塊_python
- 2022-05-27 淺談go中cgo的幾種使用方式_Golang
- 最近更新
-
- window11 系統(tǒng)安裝 yarn
- 超詳細(xì)win安裝深度學(xué)習(xí)環(huán)境2025年最新版(
- Linux 中運(yùn)行的top命令 怎么退出?
- MySQL 中decimal 的用法? 存儲小
- get 、set 、toString 方法的使
- @Resource和 @Autowired注解
- Java基礎(chǔ)操作-- 運(yùn)算符,流程控制 Flo
- 1. Int 和Integer 的區(qū)別,Jav
- spring @retryable不生效的一種
- Spring Security之認(rèn)證信息的處理
- Spring Security之認(rèn)證過濾器
- Spring Security概述快速入門
- Spring Security之配置體系
- 【SpringBoot】SpringCache
- Spring Security之基于方法配置權(quán)
- redisson分布式鎖中waittime的設(shè)
- maven:解決release錯(cuò)誤:Artif
- restTemplate使用總結(jié)
- Spring Security之安全異常處理
- MybatisPlus優(yōu)雅實(shí)現(xiàn)加密?
- Spring ioc容器與Bean的生命周期。
- 【探索SpringCloud】服務(wù)發(fā)現(xiàn)-Nac
- Spring Security之基于HttpR
- Redis 底層數(shù)據(jù)結(jié)構(gòu)-簡單動(dòng)態(tài)字符串(SD
- arthas操作spring被代理目標(biāo)對象命令
- Spring中的單例模式應(yīng)用詳解
- 聊聊消息隊(duì)列,發(fā)送消息的4種方式
- bootspring第三方資源配置管理
- GIT同步修改后的遠(yuǎn)程分支