Nginx 学习 —— 负载均衡
說到負(fù)載均衡,我想說它天生就是不公平的。為什么這么說呢?請你想象這么一個場景,一塊蛋糕切成5份,現(xiàn)在要將它分給A、B、C3個人,基于公平原則,我們說每個人正常可以分到5/3份,但是,5/3份很明顯不好進(jìn)行劃分,誒碰巧這個時候A中午沒有吃飯,能多吃幾份,B、C肚子偏飽,1份即可,基于不公平原則,我們分給A3份蛋糕,B、C個一份,這樣按照一定策略將資源進(jìn)行劃分的方式,是一種均衡的策略。
在web應(yīng)用中,一個web應(yīng)用(或者說某個服務(wù))在生產(chǎn)環(huán)境中一般是集群部署,然后采用負(fù)載均衡硬件(F5)或者軟件(nginx)將請求分發(fā)到不同的服務(wù)主機(jī)中進(jìn)行處理,很明顯,這里的蛋糕就相當(dāng)于我們的web request,假設(shè)有5個request進(jìn)來,基于一定的均衡策略,我們可能會將其中的3個request交給A服務(wù)器去處理,B、C服務(wù)器各處理1個request。下面我畫張圖片簡單說明這個模型:
?
?
那么使用負(fù)載均衡有什么好處呢?首先優(yōu)化資源利用率,最大化吞吐量,減少延遲,再者系統(tǒng)的伸縮性和可靠性也得到了相應(yīng)的保障。
一、Nginx 負(fù)載均衡及相關(guān)策略介紹
負(fù)載均衡技術(shù)少不了相關(guān)的均衡策略,Nginx 中提供了 4 種均衡策略,我們可以根據(jù)具體的業(yè)務(wù)場景選擇合適的均衡策略。下面分別介紹這 4 中均衡策略:
-
1、基于輪詢的均衡策略:
輪詢嘛,就是說對進(jìn)到nginx的request按照遍歷的方式進(jìn)行分發(fā),如果request 1 分發(fā)到 Server A,那么request 2將被分發(fā)到 Server B,......以此循環(huán)類推
-
2、基于最少連接數(shù)的均衡策略:
最少連接,也就是說nginx會判斷后端集群服務(wù)器中哪個Server當(dāng)前的 Active Connection 數(shù)是最少的,那么對于每個新進(jìn)來的request,nginx將該request分發(fā)給對應(yīng)的Server.
-
3、基于ip-hash的均衡策略:
我們都知道,每個請求的客戶端都有相應(yīng)的ip地址,該均衡策略中,nginx將會根據(jù)相應(yīng)的hash函數(shù),對每個請求的ip作為關(guān)鍵字,得到的hash值將會決定將請求分發(fā)給相應(yīng)Server進(jìn)行處理
-
4、基于加權(quán)輪詢的均衡策略:
加權(quán)輪詢,很顯然這個策略跟我們開題引入的場景是一樣的,nginx會給Server配置相應(yīng)的權(quán)重,權(quán)重越大,接收的request數(shù)將會越多
上面的均衡策略其實(shí)都非常很好理解,但是如果想了解其實(shí)現(xiàn)原理,可以看源代碼,但是小編就算了,我是看不懂C、C++的。
二、Nginx 不同均衡策略的配置介紹
-
1、基于輪詢的均衡策略:
這個是Nginx默認(rèn)的均衡算法,如果你不進(jìn)行相關(guān)的配置,默認(rèn)會執(zhí)行該策略,配置如下:
http {upstream myapp1 {server srv1.example.com;server srv2.example.com;server srv3.example.com;}server {listen 80;location / {proxy_pass http://myapp1;}} }可以看出,nginx負(fù)載均衡使用到的指令不多,其中比較重要的兩個是upstream和proxy_pass,upstream塊定義一個后端小集群,里邊配置相關(guān)的Server組成這個集群,同時upstream為這個集群起個相應(yīng)的名字,本實(shí)例叫myapp1.proxy_pass處于location塊中,表示對于所有符合/的request,將會交給哪個集群進(jìn)行處理,本實(shí)例為http://myapp1。
但又一點(diǎn)我們需要注意,上面http://myapp1中myapp1必須是upstream起的名字,對于協(xié)議是使用http還是https,都無所謂,如果你的協(xié)議使用https,則將http直接改成https即可。另外,如果你在upstream中的server指令中指定了協(xié)議名,那么在proxy_pass指令中就不需要加上協(xié)議名稱了。
nginx負(fù)載均衡使用反向代理實(shí)現(xiàn),也就是我們上面使用到的proxy_pass指令,支持的協(xié)議不止是http和https,同時還支持FastCGI、uwsgi、SCGI、memcached、gRPC,如果你需要使用除了http、https外的其他協(xié)議,我們不能使用proxy_pass指令了,應(yīng)該轉(zhuǎn)而使用相應(yīng)的指令,如fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、grpc_pass。
該策略處理負(fù)載,小編認(rèn)為還是有缺陷的,不能防止某臺Server出現(xiàn)負(fù)載過高的情況。因?yàn)槿绻行┱埱髨?zhí)行時間過長,而系統(tǒng)的并發(fā)量卻非常大,那么就可能導(dǎo)致某臺Server出現(xiàn)request堆積,負(fù)載過高,snowslide is possible~
-
2、基于最少連接數(shù)的均衡策略:
該策略主要使用了least_conn指令,具體配置如下:
upstream myapp1 {least_conn;server srv1.example.com;server srv2.example.com;server srv3.example.com;}該策略還是比較人性化的,可以按照機(jī)器的實(shí)際情況進(jìn)行剛需分配。
-
3、基于ip-hash的均衡策略:
當(dāng)然了,如果我們想實(shí)現(xiàn)這樣一個功能,我們想讓對于相同客戶端的請求每次都被分發(fā)到同一個Server進(jìn)行處理,上面兩種策略都是不做到。此策略可確保來自同一客戶端的請求始終定向到同一服務(wù)器,但此服務(wù)器不可用時除外。相關(guān)配置如下:
upstream myapp1 {ip_hash;server srv1.example.com;server srv2.example.com;server srv3.example.com; }既然相同客戶端的請求能被同一臺Server進(jìn)行處理,那么相同客戶端的會話Session就可以實(shí)現(xiàn)持久化了。
-
4、基于加權(quán)輪詢的均衡策略:
基于加權(quán)輪詢的策略就不需要過多講解了,就是在輪詢的基礎(chǔ)上加上個權(quán)重信息
upstream myapp1 {server srv1.example.com weight=3;server srv2.example.com;server srv3.example.com; }這種策略適合Server機(jī)器處理能力有區(qū)別的情況。
三、nginx 負(fù)載均衡更多高級特性及配置
-
1、健康檢查
不僅人需要體檢,機(jī)器也是需要體檢的,那么就當(dāng)nginx就是那位體檢醫(yī)生吧!nginx健康檢查是什么呢?當(dāng)我們一個request進(jìn)來被分發(fā)到相應(yīng)的Server進(jìn)行處理后,nginx會檢查該request執(zhí)行是否超時,是否執(zhí)行失敗了等情況,然后做出相應(yīng)的處理---比如說當(dāng)nginx檢查出Server A執(zhí)行某request時報出502錯誤了,那么下次nginx負(fù)載均衡時就會在upstream塊中將Server A排除掉,不分發(fā)請求給到Server A了。
對于健康檢查的功能,nginx提供了基本兩個指令,即max_fails和fail_timeout,也就是說當(dāng)nginx檢查到某Server發(fā)生錯誤的request數(shù)達(dá)到max_fails或者執(zhí)行某request執(zhí)行時間超過fail_timeout了,如果發(fā)生超時了,nginx將開始使用實(shí)時請求優(yōu)雅地探測Server,如果有響應(yīng),則認(rèn)為對應(yīng)的Server還是活著的,沒有毛病的。
-
2、更多配置
針對上面upstream塊中的server指令,其格式為:server address [parameters];,里邊的parameters可以有很多的參數(shù)類型,比如說指定某臺Server不參與負(fù)載均衡等。具體配置詳見官網(wǎng)鏈接,點(diǎn)擊此處傳送門。
總結(jié)
以上是生活随笔為你收集整理的Nginx 学习 —— 负载均衡的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Java 函数式编程和 lambda 表
- 下一篇: Nginx可以做什么?看完这篇你就懂了