負(fù)載均衡在服務(wù)端開發(fā)中算是一個(gè)比較重要的特性。因?yàn)镹ginx除了作為常規(guī)的Web服務(wù)器外，還會(huì)被大規(guī)模的用于反向代理前端，因?yàn)镹ginx的異步框架可以處理很大的并發(fā)請(qǐng)求，把這些并發(fā)請(qǐng)求hold住之后就可以分發(fā)給后臺(tái)服務(wù)端(backend servers, 后面簡(jiǎn)稱backend)來做復(fù)雜的計(jì)算、處理和響應(yīng)，并且在業(yè)務(wù)量增加的時(shí)候可以方便地?cái)U(kuò)容后臺(tái)服務(wù)器。
　　負(fù)載均衡可以分為硬件負(fù)載均衡和軟件負(fù)載均衡，前者一般是專用的軟件和硬件相結(jié)合的設(shè)備，設(shè)備商會(huì)提供完整成熟的解決方案，通常也會(huì)更加昂貴。軟件的復(fù)雜均衡以Nginx占據(jù)絕大多數(shù)，本文也是基于其手冊(cè)做相應(yīng)的學(xué)習(xí)研究的。
 
一、基本簡(jiǎn)介
　　負(fù)載均衡涉及到以下的基礎(chǔ)知識(shí)。
　　(1) 負(fù)載均衡算法
　　a. Round Robin: 對(duì)所有的backend輪訓(xùn)發(fā)送請(qǐng)求，算是最簡(jiǎn)單的方式了，也是默認(rèn)的分配方式；
　　b. Least Connections(least_conn): 跟蹤和backend當(dāng)前的活躍連接數(shù)目，最少的連接數(shù)目說明這個(gè)backend負(fù)載最輕，將請(qǐng)求分配給他，這種方式會(huì)考慮到配置中給每個(gè)upstream分配的weight權(quán)重信息；
　　c. Least Time(least_time): 請(qǐng)求會(huì)分配給響應(yīng)最快和活躍連接數(shù)最少的backend；
　　d. IP Hash(ip_hash): 對(duì)請(qǐng)求來源IP地址計(jì)算hash值，IPv4會(huì)考慮前3個(gè)octet，IPv6會(huì)考慮所有的地址位，然后根據(jù)得到的hash值通過某種映射分配到backend；
　　e. Generic Hash(hash): 以用戶自定義資源(比如URL)的方式計(jì)算hash值完成分配，其可選consistent關(guān)鍵字支持一致性hash特性；
　　(2) 會(huì)話一致性
　　用戶(瀏覽器)在和服務(wù)端交互的時(shí)候，通常會(huì)在本地保存一些信息，而整個(gè)過程叫做一個(gè)會(huì)話(Session)并用唯一的Session ID進(jìn)行標(biāo)識(shí)。會(huì)話的概念不僅用于購(gòu)物車這種常見情況，因?yàn)镠TTP協(xié)議是無狀態(tài)的，所以任何需要邏輯上下文的情形都必須使用會(huì)話機(jī)制，此外HTTP客戶端也會(huì)額外緩存一些數(shù)據(jù)在本地，這樣就可以減少請(qǐng)求提高性能了。如果負(fù)載均衡可能將這個(gè)會(huì)話的請(qǐng)求分配到不同的后臺(tái)服務(wù)端上，這肯定是不合適的，必須通過多個(gè)backend共享這些數(shù)據(jù)，效率肯定會(huì)很低下，最簡(jiǎn)單的情況是保證會(huì)話一致性——相同的會(huì)話每次請(qǐng)求都會(huì)被分配到同一個(gè)backend上去。
　　(3) 后臺(tái)服務(wù)端的動(dòng)態(tài)配置
　　出問題的backend要能被及時(shí)探測(cè)并剔除出分配群，而當(dāng)業(yè)務(wù)增長(zhǎng)的時(shí)候可以靈活的添加backend數(shù)目。此外當(dāng)前風(fēng)靡的Elastic Compute云計(jì)算服務(wù)，服務(wù)商也應(yīng)當(dāng)根據(jù)當(dāng)前負(fù)載自動(dòng)添加和減少backend主機(jī)。
　　(4) 基于DNS的負(fù)載均衡
　　通?，F(xiàn)代的網(wǎng)絡(luò)服務(wù)者一個(gè)域名會(huì)關(guān)連到多個(gè)主機(jī)，在進(jìn)行DNS查詢的時(shí)候，默認(rèn)情況下DNS服務(wù)器會(huì)以round-robin形式以不同的順序返回IP地址列表，因此天然將客戶請(qǐng)求分配到不同的主機(jī)上去。不過這種方式含有固有的缺陷：DNS不會(huì)檢查主機(jī)和IP地址的可訪問性，所以分配給客戶端的IP不確保是可用的(Google 404)；DNS的解析結(jié)果會(huì)在客戶端、多個(gè)中間DNS服務(wù)器不斷的緩存，所以backend的分配不會(huì)那么的理想。
　　二、Nginx中的負(fù)載均衡
　　Nginx中的負(fù)載均衡配置在 手冊(cè) 中描述的極為細(xì)致，此處就不流水帳了。對(duì)于常用的HTTP負(fù)載均衡，主要先定義一個(gè)upstream作為backend group，然后通過proxy_pass/fastcgi_pass等方式進(jìn)行轉(zhuǎn)發(fā)操作，其中fastcgi_pass幾乎算是Nginx+PHP站點(diǎn)的標(biāo)配了。
　　2.1 會(huì)話一致性
　　Nginx中的會(huì)話一致性是通過sticky開啟的，會(huì)話一致性和之前的負(fù)載均衡算法之間并不沖突，只是需要在第一次分配之后，該會(huì)話的所有請(qǐng)求都分配到那個(gè)相同的backend上面。目前支持三種模式的會(huì)話一致性：
　　(1). Cookie Insertion
　　在backend第一次response之后，會(huì)在其頭部添加一個(gè)session cookie，之后客戶端接下來的請(qǐng)求都會(huì)帶有這個(gè)cookie值，Nginx可以根據(jù)這個(gè)cookie判斷需要轉(zhuǎn)發(fā)給哪個(gè)backend了。
　　sticky cookie srv_id expires=1h domain=.example.com path=/;
　　上面的srv_id代表了cookie的名字，而后面的參數(shù)expires、domain、path都是可選的。
　　(2). Sticky Routes
　　也是在backend第一次response之后，會(huì)產(chǎn)生一個(gè)route信息，route信息通常會(huì)從cookie/URI信息中提取。
　　sticky route $route_cookie $route_uri;
　　這樣Nginx會(huì)按照順序搜索routecookie、routecookie、route_uri參數(shù)并選擇第一個(gè)非空的參數(shù)用作route，而如果所有的參數(shù)都是空的，就使用上面默認(rèn)的負(fù)載均衡算法決定請(qǐng)求分發(fā)給哪個(gè)backend。
　　(3). Learn
　　較為的復(fù)雜也較為的智能，Nginx會(huì)自動(dòng)監(jiān)測(cè)request和response中的session信息，而且通常需要回話一致性的請(qǐng)求、應(yīng)答中都會(huì)帶有session信息，這和第一種方式相比是不用增加cookie，而是動(dòng)態(tài)學(xué)習(xí)已有的session。
　　這種方式需要使用到zone結(jié)構(gòu)，在Nginx中zone都是共享內(nèi)存，可以在多個(gè)worker process中_共享數(shù)據(jù)用的。(不過其他的會(huì)話一致性怎么沒用到共享內(nèi)存區(qū)域呢？)
　　sticky learn
　　create=$upstream_cookie_examplecookie
　　lookup=$cookie_examplecookie
　　zone=client_sessions:1m
　　timeout=1h;
　　2.2 Session Draining
　　主要是有需要關(guān)閉某些backend以便維護(hù)或者升級(jí)，這些關(guān)鍵性的服務(wù)都講求gracefully處理的：就是新的請(qǐng)求不會(huì)發(fā)送到這個(gè)backend上面，而之前分配到這個(gè)backend的會(huì)話的后續(xù)請(qǐng)求還會(huì)繼續(xù)發(fā)送給他，直到這個(gè)會(huì)話最終完成。
　　讓某個(gè)backend進(jìn)入draining的狀態(tài)，既可以直接修改配置文件，然后按照之前的方式通過向master process發(fā)送信號(hào)重新加載配置，也可以采用Nginx的on-the-fly配置方式。
　　$ curl http://localhost/upstream_conf?upstream=backend
　　$ curl http://localhost/upstream_conf?upstream=backend\&id=1\&drain=1
　　通過上面的方式，先列出各個(gè)bacnkend的ID號(hào)，然后drain指定ID的backend。通過在線觀測(cè)backend的所有session都完成后，該backend就可以下線了。
　　2.3 backend健康監(jiān)測(cè)
　　backend出錯(cuò)會(huì)涉及到兩個(gè)參數(shù)，max_fails=1 fail_timeout=10s;意味著只要Nginx向backend發(fā)送一個(gè)請(qǐng)求失敗或者沒有收到一個(gè)響應(yīng)，就認(rèn)為該backend在接下來的10s是不可用的狀態(tài)。
　　通過周期性地向backend發(fā)送特殊的請(qǐng)求，并期盼收到特殊的響應(yīng)，可以用以確認(rèn)backend是健康可用的狀態(tài)。通過health_check可以做出這個(gè)配置。
　　match server_ok {
　　status 200-399;
　　header Content-Type = text/html;
　　body !~ "maintenance mode";
　　}
　　server {
　　location / {
　　proxy_pass http://backend;
　　health_check interval=10 fails=3 passes=2 match=server_ok;
　　}
　　}
　　上面的health_check是必須的，后面的參數(shù)都是可選的。尤其是后面的match參數(shù)，可以自定義服務(wù)器健康的條件，包括返回狀態(tài)碼、頭部信息、返回body等，這些條件是&&與關(guān)系。默認(rèn)情況下Nginx會(huì)相隔interval的間隔向backend group發(fā)送一個(gè)”/“的請(qǐng)求，如果超時(shí)或者返回非2xx/3xx的響應(yīng)碼，則認(rèn)為對(duì)應(yīng)的backend是unhealthy的，那么Nginx會(huì)停止向其發(fā)送request直到下次改backend再次通過檢查。
　　在使用了health)check功能的時(shí)候，一般都需要在backend group開辟一個(gè)zone，在共享backend group配置的同時(shí)，所有backend的狀態(tài)就可以在所有的worker process所共享了，否則每個(gè)worker process獨(dú)立保存自己的狀態(tài)檢查計(jì)數(shù)和結(jié)果，兩種情況會(huì)有很大的差異哦。
　　2.4 通過DNS設(shè)置HTTP負(fù)載均衡
　　Nginx的backend group中的主機(jī)可以配置成域名的形式，如果在域名的后面添加resolve參數(shù)，那么Nginx會(huì)周期性的解析這個(gè)域名，當(dāng)域名解析的結(jié)果發(fā)生變化的時(shí)候會(huì)自動(dòng)生效而不用重啟。
　　http {
　　resolver 10.0.0.1 valid=300s ipv6=off;
　　resolver_timeout 10s;
　　server {
　　location / {
　　proxy_pass http://backend;
　　}
　　}
　　upstream backend {
　　zone backend 32k;
　　least_conn;
　　...
　　server backend1.example.com resolve;
　　server backend2.example.com resolve;
　　}
　　}
　　如果域名解析的結(jié)果含有多個(gè)IP地址，這些IP地址都會(huì)保存到配置文件中去，并且這些IP都參與到自動(dòng)負(fù)載均衡。
　　2.5 TCP/UDP流量的負(fù)載均衡
　　除了專長(zhǎng)的HTTP負(fù)載均衡，Nginx還支持TCP和UDP流量的負(fù)載均衡，適用于LDAP/MySQL/RTMP和DNS/syslog/RADIUS各種應(yīng)用場(chǎng)景。這類情況的負(fù)載均衡使用stream來配置，Nginx編譯的時(shí)候需要支持–with-stream選項(xiàng)。查看 手冊(cè) ，其配置原理和參數(shù)和HTTP負(fù)載均衡差不多。
　　因?yàn)門CP、UDP的負(fù)載均衡都是針對(duì)通用程序的，所以之前HTTP協(xié)議支持的match條件(status、header、body)是沒法使用的。TCP和UDP的程序可以根據(jù)特定的程序，采用send、expect的方式來進(jìn)行動(dòng)態(tài)健康檢測(cè)。
　　match http {
　　send "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n";
　　expect ~* "200 OK";
　　}
　　2.6 其他特性
　　slow_start=30s：防止新添加/恢復(fù)的主機(jī)被突然增加的請(qǐng)求所壓垮，通過這個(gè)參數(shù)可以讓該主機(jī)的weight從0開始慢慢增加到設(shè)定值，讓其負(fù)載有一個(gè)緩慢增加的過程。
　　max_conns=30：可以設(shè)置backend的最大連接數(shù)目，當(dāng)超過這個(gè)數(shù)目的時(shí)候會(huì)被放到queue隊(duì)列中，同時(shí)隊(duì)列的大小和超時(shí)參數(shù)也可以設(shè)置，當(dāng)隊(duì)列中的請(qǐng)求數(shù)大于設(shè)定值，或者超過了timeout但是backend還不能處理請(qǐng)求，則客戶端將會(huì)收到一個(gè)錯(cuò)誤返回。通常來說這還是一個(gè)比較重要的參數(shù)，因?yàn)镹ginx作為反向代理的時(shí)候，通常就是用于抗住并發(fā)量的，如果給backend過多的并發(fā)請(qǐng)求，很可能會(huì)占用后端過多的資源(比如線程、進(jìn)程非事件驅(qū)動(dòng))，最終反而會(huì)影響backend的處理能力。

來源：Nicol的博客銘