(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ù)載均衡
通常現(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，即由負(fù)載均衡器向客戶端植入 cookie，之后客戶端接下來的請(qǐng)求都會(huì)帶有這個(gè)cookie值，Nginx可以根據(jù)這個(gè)cookie判斷需要轉(zhuǎn)發(fā)給哪個(gè)backend了。
(2)Sticky Routes　
也是在backend第一次response之后，會(huì)產(chǎn)生一個(gè)route信息，route信息通常會(huì)從cookie/URI信息中提取。
這樣Nginx會(huì)按照順序搜索routecookie、route_uri參數(shù)并選擇第一個(gè)非空的參數(shù)用作route，而如果所有的參數(shù)都是空的，就使用上面默認(rèn)的負(fù)載均衡算法決定請(qǐng)求分發(fā)給哪個(gè)backend。