大家好，今天來為大家分享nginx負載均衡原理的一些知識點，和nginx集群如何實現實例動態感知的問題解析，大家要是都明白，那么可以忽略，如果不太清楚的話可以看看本篇文章，相信很大概率可以解決您的問題，接下來我們就一起來看看吧！
nginx的負載均衡如何配置
nginx的負載均衡有4種模式：
1)、輪詢（默認）
每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。
2)、weight
指定輪詢幾率，weight和訪問比率成正比，用于后端服務器性能不均的情況。
2)、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。
3)、fair（第三方）
按后端服務器的響應時間來分配請求，響應時間短的優先分配。
4)、url_hash（第三方）
配置方法：
打開nginx.cnf文件
在http節點下添加upstream節點：
upstreamwebname{
server192.168.0.1:8080;
server192.168.0.2:8080;
}
其中webname是自己取的名字，最后會通過這個名字在url里訪問的，像上面這個例子一樣什么都不加就是默認的輪詢，第一個請求過來訪問第一個server，第二個請求來訪問第二個server。依次輪著來。
upstreamwebname{
server192.168.0.1:8080weight2;
server192.168.0.2:8080weight1;
}
這個weight也很好理解，權重大的被訪問的概率就大，上面這個例子的話，訪問2次server1，訪問一次server2
upstreamwebname{
ip_hash;
server192.168.0.1:8080;
server192.168.0.2:8080;
}
ip_hash的配置也很簡單，直接加一行就可以了，這樣只要是同一個ip過來的都會到同一臺server上
然后在server節點下進行配置：
location/name{
proxy_passhttp://webname/name/;
proxy_http_version1.1;
proxy_set_headerUpgrade$http_upgrade;
proxy_set_headerConnection"upgrade";
}
proxy_pass里面用上面配的webname代替了原來的ip地址。
這樣就基本完成了負載均衡的配置。
下面是主備的配置：
還是在upstream里面
upstreamwebname{
server192.168.0.1:8080;
server192.168.0.2:8080backup;
}
設置某一個節點為backup，那么一般情況下所有請求都訪問server1，當server1掛掉或者忙的的時候才會訪問server2
upstreamwebname{
server192.168.0.1:8080;
server192.168.0.2:8080down;
}
設置某個節點為down，那么這個server不參與負載。
nginx究竟使用了什么樣的負載均衡策略
這個問題問得可就有點門外漢的意思了。。。
nginx作為一款負載均衡服務組件，憑借其近乎絕對穩定，性能優異等特性，成為企業級大應用中不可或缺的均衡工具！
nginx使用反向代理實現，在訪問者(通常為瀏覽器)與應用服務器之間進行解耦，將收到的請求通過一定的負載均衡策略分配到不同的應用服務器上，原本使用一臺服務器提供服務，現在通過這樣的nginx集群應用服務，對外提供強大的，透明的服務，單一應用服務器的不穩定性也可完美解決！
由此可見，nginx是對外提供負載均衡的服務組件，可提供的負載均衡策略包括但不限于以下幾種:
1，輪詢:每臺應用服務器平均的接受到請求。
默認方式:只要通過server配置了多臺應用服務器，就能默認輪詢！
2，weight:按照一定的權重，分配到不同的機器上不同的訪問數。
通過weight＝4;這樣的句式來配置！
3，ip_hash:通過ip進行hash進行訪問服務器分配，可解決上訴輪詢的session不在一臺機器的情況
使用ip_hash開啟！
4，fair:按照應用服務的響應時間動態分配服務器。
5，url_hash:通過url進行hash分配到應用服務器上。
一般選擇那種負載均衡方式還需要通過業務，整個架構來確定，nginx基于簡單配置，就可以實現強大的性能，是開發者不可或缺的強大工具，更多的技術分享，敬請關注。。
nginx負載均衡時候cookie怎么攜帶
nginx負載均衡cookie攜帶就是ginx-sticky-module是Nginx的一個擴展模塊，實現了通過Cookie的會話粘貼效果。
Nginx以前對session保持支持不太好，主要采用ip_hash把同一來源的客戶(同一C段的IP)固定指向后端的同一臺機器，ip_hash有個缺點是不能實現很好的負載均衡；直到nginx的擴展模塊nginx-sticky-module的出現，解決了sessionsticky的問題。
基本的原理：
首先根據輪詢RR隨機到某臺后端，然后在響應的Set-Cookie上加上route=md5(upstream)字段，第二次請求再處理的時候，發現有route字段，直接導向原來的那個節點。
用nginx這個反向代理服務器實現負載均衡，集群幾臺服務器，同時協作完成一個任務，這樣的情景下就是分布式嗎
先說結論，可以利用Nginx的反向代理能力，集合幾個負責不同功能的server節點，從而實現分布式；也可以利用Nginx的負載均衡能力，集合幾個相同功能的server節點，從而實現服務的高穩定性。
目前Nginx已經逐漸成為平臺服務必不可少的一環，就是因為它的反向代理與負載均衡能力滿足了開發者對產品服務高可用性以及模塊解耦的需求。
接下來我們分別來解釋反向代理與負載均衡。
反向代理反向代理是針對服務器端。對于用戶來說，他只知道反向代理服務器的地址，但是反向代理服務器后面通常指向了多個服務器，負責了相同或者不同的模塊。Nginx會根據conf文件中配置的正則表達式來解析用戶實際請求的urlpath，然后再將請求轉發至不同的服務器進行處理，最后再將請求結果返回給用戶。這個過程就叫做反向代理，因此可以看做將不同的能力，不同的server整合到一個host和ip，從而減少用戶的使用負擔，也是對用戶更加友好。
負載均衡與反向代理相對應的是負載均衡。
我通過一個例子來解釋，當一臺服務器能夠承受的qps只有2000，但是當前用戶量激增，qps達到了3500，在不修改代碼不優化的情況下如何解決呢。
我們可以再布置一臺server，兩臺服務器一起處理請求，從整體上來看，qps就達到了4000。但是兩臺服務器有不同的ip，我們總不能在擴容后和用戶說，你的第奇數個請求發到8080端口，第偶數個請求發送到8082吧。
如何處理這個問題呢？這就用到了負載均衡。
我們可以在Nginx的conf文件中為同一個類型的path配置指向兩臺服務器地址，這樣對于用戶來說，他依然只需要請求Nginx的地址即可，Nginx會根據當前兩臺服務器的情況決定將請求轉發給哪一個。這樣布置還有一個好處，就是如果其中一個節點宕機了，只要另一個節點還活著，從用戶的角度，整個服務就還能夠運轉，因為Nginx會將請求轉給有正常反饋的server。
我曾經嘗試過，在兩臺服務器一樣壓力的情況下，請求是均勻分給兩個不同的服務器的。
基于我相信大家已經對我說的“利用Nginx的反向代理能力，集合幾個負責不同功能的server節點，從而實現分布式；也可以利用Nginx的負載均衡能力，集合幾個相同功能的server節點，從而實現服務的高穩定性”有了進一步的了解了。
以上是我的淺見，歡迎大家在下方評論留言。
我是蘇蘇思量，來自BAT的Java開發工程師，每天分享科技類見聞，歡迎關注我，與我共同進步。
nginx做負載均衡，怎么在有宕機情況出現時保
那就搭建2個nginx服務器做負載均衡，然后都安裝keepalived，第一臺宕機，第二臺自動啟用
關于nginx負載均衡原理到此分享完畢，希望能幫助到您。
