nginx的常用負載均衡
HTTP 重定向
對于HTTP 重定向抵碟，你一定不陌生，它可以將 HTTP 請求進行轉移，在 Web 開發(fā)中我們經(jīng)常會用它來完成自動跳轉膀篮，比如用戶登錄成功后跳轉到相應的管理頁面毯焕。 這種重定向完全由HTTP 定義衍腥，并且由HTTP 代理和Web 服務器共同實現(xiàn)磺樱。很簡單，當HTTP 代理（比如瀏覽器）向Web服務器請求某個URL后婆咸，Web 服務器可以通過HTTP 響應頭信息中的Location 標記來返回一個新的URL竹捉，這意味著HTTP代理需要繼續(xù)請求這個新的URL ，這便完成了自動跳轉尚骄。當然块差，如果你自己寫了一個 HTTP 代理，也可以不支持重定向倔丈，也就是對于Web 服務器返回的Location 標記視而不見憨闰，雖然這可能不符合HTTP 標準，但這完全取決于你的應用需要需五。 也正是因為HTTP 重定向具備了請求轉移和自動跳轉的本領鹉动，所以除了滿足應用程序需要的各種自動跳轉之外，它還可以用于實現(xiàn)負載均衡宏邮，以達到Web 擴展的目的泽示。
DNS 負載均衡
我們知道，DNS負責提供域名解析服務蜜氨，當我們訪問某個站點時械筛，實際上首先需要通過該站點域名的DNS服務器來獲取域名指向的IP 地址，在這一過程中飒炎，DNS服務器完成了域名到IP 地址的映射埋哟，同樣，這種映射也可以是一對多的郎汪，這時候定欧，DNS 服務器便充當了負載均衡調(diào)度器（也稱均衡器），它就像前面提到的重定向轉移策略一樣怒竿，將用戶的請求分散到多臺服務器上砍鸠，但是它的實現(xiàn)機制完全不同。
反向代理負載均衡
反向代理服務器的核心工作便是轉發(fā) HTTP 請求耕驰，因此它工作在 HTTP 層面爷辱，也就是 TCP 七層結構中的應用層（第七層），所以基于反向代理的負載均衡也稱為七層負載均衡朦肘，實現(xiàn)它并不困難饭弓，目前幾乎所有主流的 Web 服務器都熱衷于支持基于反向代理的負載均衡，隨后我們將進行Nginx反向代理負載均衡的實驗
IP 負載均衡
事實上媒抠，在數(shù)據(jù)鏈路層（第二層）弟断、網(wǎng)絡層（第三層）以及傳輸層（四層）都可以實現(xiàn)不同機制的負載均衡，但有所不同的是趴生，這些負載均衡調(diào)度器的工作必須由Linux 內(nèi)核來完成阀趴，因為我們希望網(wǎng)絡數(shù)據(jù)包在從內(nèi)核緩沖區(qū)進入進程用戶地址空間之前昏翰，盡早地被轉發(fā)到其他實際服務器上，沒錯刘急，Linux 內(nèi)核當然可以辦得到棚菊，位于內(nèi)核的Netfilter和IPVS可以解決問題，而用戶空間的應用程序?qū)Υ藚s束手無策叔汁。 另一方面统求，也正是因為可以將調(diào)度器工作在應用層以下，這些負載均衡系統(tǒng)可以支持更多的網(wǎng)絡服務協(xié)議据块，比如FTP 码邻、SMTP 、DNS 另假，以及流媒體和Vo I P 等應用冒滩。
兩個進程分享
孤兒進程
一個父進程退出，而它的一個或多個子進程還在運行浪谴，那么那些子進程將成為孤兒進程。孤兒進程將被init進程(進程號為1)所收養(yǎng)因苹，并由init進程對它們完成狀態(tài)收集工作苟耻。孤兒進程是沒有父進程的進程，孤兒進程這個重任就落到了init進程身上扶檐，init進程就好像是一個民政局凶杖，專門負責處理孤兒進程的善后工作。每當出現(xiàn)一個孤兒進程的時候款筑，內(nèi)核就把孤 兒進程的父進程設置為init智蝠，而init進程會循環(huán)地wait()它的已經(jīng)退出的子進程。這樣奈梳，當一個孤兒進程凄涼地結束了其生命周期的時候杈湾，init進程就會代表黨和政府出面處理它的一切善后工作。因此孤兒進程并不會有什么危害
僵尸進程
一個子進程在其父進程還沒有調(diào)用wait()或waitpid()的情況下退出攘须。這個子進程就是僵尸進程漆撞。任何一個子進程(init除外)在exit()之后，并非馬上就消失掉于宙，而是留下一個稱為僵尸進程(Zombie)的數(shù)據(jù)結構浮驳，等待父進程處理。這是每個 子進程在結束時都要經(jīng)過的階段捞魁。如果子進程在exit()之后至会，父進程沒有來得及處理，那么保留的那段信息就不會釋放谱俭，其進程號就會一直被占用奉件，但是系統(tǒng)所能使用的進程號是有限的宵蛀，如果大量的產(chǎn)生僵死進程，將因為沒有可用的進程號而導致系統(tǒng)不能產(chǎn)生新的進程. 此即為僵尸進程的危害瓶蚂，應當避免糖埋。
