最近專案要設計到併發，所以設計專案架構時考慮到用nginx搭建tomcat集群，再用redis搭建分布式session，下面將一步步分享我摸索的過程。
nginx的負載均衡模組upstream模組主要支援如下4中排程演算法：
1、伺服器輪詢（預設方式）：每個請求訪問按照時間順序逐一分配到不同的伺服器端，如果後端某台伺服器宕機時，故障系統會被自動的剔除，使使用者訪問不受影響。weight（權重）指定輪詢的權值，weight值越大，分配到的訪問機率越高，主要用於伺服器端效能不均的情況下。
2、ip_hash：每個請求按照訪問的ip的hash值進行分配，這行來自同乙個ip的使用者將會固定到後端的乙個伺服器，固定伺服器後可以有效的解決網頁存在的session共享的問題。
4、url_hash：此排程演算法是根據訪問的url的hash結果來分配請求，使每個url定向到同乙個後端伺服器，可以進一步的提高後端伺服器的效率。nginx本身未整合該模組，如果使用需安裝nginx的hash包，並編譯載入到nginx。
在http的upstream模組中，可以通過server指令指定後端伺服器的ip位址和埠，同時還可以設定每個後端伺服器在負載均衡排程中的狀態。通常設定的狀態引數如下：
1、down：表示當前的server暫時不參與負載均衡。
2、backup：預留的備份伺服器。當其他的所有非backup機器出現故障或者忙的時間，才會請求backup伺服器，因此這台伺服器的壓力最輕。
3、max_fails：允許請求失敗的次數，預設為1。當超過最大次數時，返回proxy_next_upstream 模組定義的錯誤。
4、fail_timeout：在經歷了max_fails次失敗後，暫停服務的時間。max_fails可以和fail_timeout一起使用。
注：當負載均衡排程演算法使用ip_hash時，後端伺服器在負載均衡排程中的狀態不能是weight和backup。
現在在192.168.1.110上部署的是nginx，192.168.1.110和192.168.111上部署的tomcat伺服器。
1、當開啟 時，nginx負載集群採用預設方式時，每次都會輪詢伺服器。
如下：
此種方法不能夠解決集群的session問題。
2、當採用ip_hash時，重新整理一直是固定的伺服器
這種方式解決了session問題，如果192.168.1.110伺服器宕機掉的話，nginx會將請求轉到未宕機的伺服器上面（經測試，將192.168.1.110伺服器shutdown，再此請求會跳轉 到192.168.1.111伺服器）。但是也存在個問題，當hash到的伺服器宕機，nginx調到另乙個伺服器，自然session會丟失。
3、剩餘的兩種安裝nginx所需對應的模組，和上面同理就不在測試。
無論是採用哪種負載均衡方式，都會出現session丟失問題。要解決該問題，要對session單另存放，無論是存庫，檔案，還是分布式記憶體伺服器存放，是集群搭建必不可少的。下篇將測試並解決session問題
負載平衡問題
難怪評藍題，實在是太裸了。源點向每個點連邊，容量為這個點的現有貨物數。每個點向匯點連邊，容量為要求即sum n。每個點向其相鄰兩點連邊，容量無限，費用為1。然後跑一遍源點到匯點的費用流。看 includeusing namespace std define int long long define ...
ActiveMQ 集群負載平衡
目前的架構 負載均衡方案 第二種方案呢，假設我們整個應用是個食堂，這個食堂裡面有好多飯口，每個飯口有好多大爺大媽 咦 每個飯口實現了高可用，即使有大媽不上班，還有大爺頂上。針對好多學生 使用者 實現了負載均衡，學生被基本均勻的分配到每乙個飯口上。食堂 應用 飯口 集群 大媽 伺服器 現在我們利用br...
負載平衡問題（網路流）
建圖最大流即可，注意可以在連續運輸多次，剛開始直接從xi連向相鄰的yi了，這樣只是運輸一次，沒有考慮到運輸多次的情況 拆點，分xiyi，對應每個倉庫。從源點向xi連邊，容量為ri，費用為0 從yi向匯點連邊，容量為xba，費用為0 從xi向對應的yi連邊，容量為inf，費用為0 從yi向環形相鄰的x...