這裡對負載均衡概念和nginx負載均衡實作方式做一個總結：
先說一下負載均衡的概念：
Load Balance負載均衡是用于解決一台機器(一個程序)無法解決所有請求而産生的一種算法。
我們知道單台伺服器的性能是有上限的，當流量很大時，就需要使用多台伺服器來共同提供服務，這就是所謂的叢集。
負載均衡伺服器，就是用來把經過它的流量，按照某種方法，配置設定到叢集中的各台伺服器上。
這樣一來不僅可以承擔更大的流量、降低服務的延遲，還可以避免單點故障造成服務不可用。
一般的反向代理伺服器，都具備負載均衡的功能。負載均衡功能可以由硬體來提供，比如以前的F5裝置。
也可以由軟體來提供，LVS可以提供四層的負載均衡(利用IP和端口)，Haproxy和Nginx可以提供七層的負載均衡(利用應用層資訊)。
像nginx可以使用負載均衡配置設定流量，ribbon為用戶端提供負載均衡，dubbo服務調用裡的負載均衡等等，很多地方都使用到了負載均衡。
使用負載均衡帶來的好處很明顯：
當叢集裡的1台或者多台伺服器down的時候，剩餘的沒有down的伺服器可以保證服務的繼續使用
使用了更多的機器保證了機器的良性使用，不會由于某一高峰時刻導緻系統cpu急劇上升
負載均衡有好幾種實作政策，常見的有：
随機 (Random)
輪詢 (RoundRobin)
一緻性哈希 (ConsistentHash)
哈希 (Hash)
權重（Weighted）
Nginx目前提供的負載均衡子產品：
ngx_http_upstream_round_robin，權重輪詢，可均分請求，是預設的HTTP負載均衡算法，內建在架構中。
ngx_http_upstream_ip_hash_module，IP哈希，可保持會話。
ngx_http_upstream_least_conn_module，最少連接配接數，可均分連接配接。
ngx_http_upstream_hash_module，一緻性哈希，可減少緩存資料的失效。
1、輪詢
輪詢即Round Robin，根據Nginx配置檔案中的順序，依次把用戶端的Web請求分發到不同的後端伺服器。
配置的例子如下：
http{
upstream sampleapp {
server <<dns entry or IP Address(optional with port)>>;
server <<another dns entry or IP Address(optional with port)>>;
}
....
server{
listen 80;
...
location / {
proxy_pass http://sampleapp;
}
上面隻有1個DNS入口被插入到upstream節，即sampleapp，同樣也在後面的proxy_pass節重新提到。
執行個體：
http {
upstream myservers{
server 134.56.56.4:8001;
server 134.56.56.4:8002;
server 134.56.52.4:8011;
server 134.56.52.4:8012;
}
server {
listen 80;
location / {
proxy_pass http://myservers;
}
}
2、最少連接配接
Web請求會被轉發到連接配接數最少的伺服器上。
們知道輪詢算法是把請求平均的轉發給各個後端，使它們的負載大緻相同。
這有個前提，就是每個請求所占用的後端時間要差不多，如果有些請求占用的時間很長，會導緻其所在的後端
負載較高。在這種場景下，把請求轉發給連接配接數較少的後端，能夠達到更好的負載均衡效果，這就是least_conn算法。
least_conn算法很簡單，首選周遊後端叢集，比較每個後端的conns/weight，選取該值最小的後端。
如果有多個後端的conns/weight值同為最小的，那麼對它們采用權重輪詢算法。
upstream sampleapp {
least_conn;
server <<dns entry or IP Address(optional with port)>>;
server <<another dns entry or IP Address(optional with port)>>;
}
....
server{
listen 80;
...
location / {
proxy_pass http://sampleapp;
上面的例子隻是在upstream節添加了least_conn配置。其它的配置同輪詢配置。
3、IP位址哈希
前述的兩種負載均衡方案中，同一用戶端連續的Web請求可能會被分發到不同的後端伺服器進行處理，是以如果涉及到會話Session，那麼會話會比較複雜。
常見的是基于資料庫的會話持久化。
要克服上面的難題，可以使用基于IP位址哈希的負載均衡方案。
這樣的話，同一用戶端連續的Web請求都會被分發到同一伺服器進行處理。
ip_hash算法的原理很簡單，根據請求所屬的用戶端IP計算得到一個數值，然後把請求發往該數值對應的後端。
是以同一個用戶端的請求，都會發往同一台後端，除非該後端不可用了。ip_hash能夠達到保持會話的效果。
ip_hash是基于round robin的，判斷後端是否可用的方法是一樣的。
第一步，根據用戶端IP計算得到一個數值。
hash1 = (hash0 * 113 + addr[0]) % 6271;
hash2 = (hash1 * 113 + addr[1]) % 6271;
hash3 = (hash2 * 113 + addr[2]) % 6271;
hash3就是計算所得的數值，它隻和初始數值hash0以及用戶端的IP有關。
第二步，根據計算所得數值，找到對應的後端。
w = hash3 % total_weight;
while (w >= peer->weight) {
w -= peer->weight;
peer = peer->next;
p++;
}
total_weight為所有後端權重之和。周遊後端連結清單時，依次減去每個後端的權重，直到w小于某個後端的權重。
標明的後端在連結清單中的序号為p。因為total_weight和每個後端的weight都是固定的，是以如果hash3值相同，
則找到的後端相同。
ip_hash;
上面的例子隻是在upstream節添加了ip_hash配置。其它的配置同輪詢配置。
4、基于權重的負載均衡
基于權重的負載均衡即Weighted Load Balancing，這種方式下，我們可以配置Nginx把請求更多地分發到高配置的後端伺服器上，把相對較少的請求分發到低配伺服器。
這就是所謂的權重輪詢，看起來很簡單，但是最早使用的權重輪詢算法有個問題，就是7個請求對應的
後端序列是這樣的：{ c, b, a, a, a, a, a }，會有5個連續的請求落在後端a上，分布不太均勻。
目前使用的權重輪詢叫做平滑的權重輪詢（smooth weighted round-robin balancing），它和前者的差別是：
每7個請求對應的後端序列為 { a, a, b, a, c, a, a }，轉發給後端a的5個請求現在分散開來，不再是連續的。
server <<dns entry or IP Address(optional with port)>> weight=2;
}
上面的例子在伺服器位址和端口後weight=2的配置，這意味着，每接收到3個請求，前2個請求會被分發到第一個伺服器，第3個請求會分發到第二個伺服器，其它的配置同輪詢配置。
還要說明一點，基于權重的負載均衡和基于IP位址哈希的負載均衡可以組合在一起使用。
關于多節點叢集部署帶來的session問題，我使用了緩存技術，緩存可以使用memcached，也可以使用redis。
由于srping-session 和spring-data-redis由很好的支援，是以我采用了redis解決session共享問題。
![Centos 7 Apache配置虛拟主機[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)