(3) 后臺服務端的動態(tài)配置
出問題的backend要能被及時探測并剔除出分配群，而當業(yè)務增長的時候可以靈活的添加backend數(shù)目。此外當前風靡的Elastic Compute云計算服務，服務商也應當根據(jù)當前負載自動添加和減少backend主機。
(4) 基于DNS的負載均衡
通?，F(xiàn)代的網(wǎng)絡服務者一個域名會關(guān)連到多個主機，在進行DNS查詢的時候，默認情況下DNS服務器會以round-robin形式以不同的順序返回IP地址列表，因此天然將客戶請求分配到不同的主機上去。不過這種方式含有固有的缺陷：DNS不會檢查主機和IP地址的可訪問性，所以分配給客戶端的IP不確保是可用的(Google 404)；DNS的解析結(jié)果會在客戶端、多個中間DNS服務器不斷的緩存，所以backend的分配不會那么的理想。
二、Nginx中的負載均衡　
Nginx中的負載均衡配置在手冊中描述的極為細致，此處就不流水帳了。對于常用的HTTP負載均衡，主要先定義一個upstream作為backend group，然后通過proxy_pass/fastcgi_pass等方式進行轉(zhuǎn)發(fā)操作，其中fastcgi_pass幾乎算是Nginx+PHP站點的標配了。
2.1 會話一致性　
Nginx中的會話一致性是通過sticky開啟的，會話一致性和之前的負載均衡算法之間并不沖突，只是需要在第一次分配之后，該會話的所有請求都分配到那個相同的backend上面。目前支持三種模式的會話一致性：　
(1)Cookie Insertion
在backend第一次response之后，會在其頭部添加一個session cookie，即由負載均衡器向客戶端植入 cookie，之后客戶端接下來的請求都會帶有這個cookie值，Nginx可以根據(jù)這個cookie判斷需要轉(zhuǎn)發(fā)給哪個backend了。
(2)Sticky Routes　
也是在backend第一次response之后，會產(chǎn)生一個route信息，route信息通常會從cookie/URI信息中提取。
這樣Nginx會按照順序搜索routecookie、route_uri參數(shù)并選擇第一個非空的參數(shù)用作route，而如果所有的參數(shù)都是空的，就使用上面默認的負載均衡算法決定請求分發(fā)給哪個backend。