負載均衡（Load Balance）是分佈式系統架構設計中必須考慮的因素之一，它通常是指，將請求/數據【均勻】分攤到多個操作單元上執行，負載均衡的關鍵在於【均勻】。常見互聯網分佈式架構如上，分爲客戶端層、反向代理nginx層、站點層、服務層、數據層。
什麼是負載均衡
負載均衡(Load Balance)是分佈式系統架構設計中必須考慮的因素之一，它通常是指，將請求/數據【均勻】分攤到多個操作單元上執行，負載均衡的關鍵在於【均勻】。
常見的負載均衡方案
常見互聯網分佈式架構如上，分爲客戶端層、反向代理nginx層、站點層、服務層、數據層。可以看到，每一個下游都有多個上游調用，只需要做到，每一個上游都均勻訪問每一個下游，就能實現“將請求/數據【均勻】分攤到多個操作單元上執行”。
【客戶端層->反向代理層】的負載均衡
【客戶端層】到【反向代理層】的負載均衡，是通過“DNS輪詢”實現的：DNS-server對於一個域名配置了多個解析ip，每次DNS解析請求來訪問DNS-server，會輪詢返回這些ip，保證每個ip的解析概率是相同的。這些ip就是nginx的外網ip，以做到每臺nginx的請求分配也是均衡的。
【反向代理層->站點層】的負載均衡
【反向代理層】到【站點層】的負載均衡，是通過“nginx”實現的。通過修改nginx.conf，可以實現多種負載均衡策略：
1)請求輪詢：和DNS輪詢類似，請求依次路由到各個web-server
2)最少連接路由：哪個web-server的連接少，路由到哪個web-server
3)ip哈希：按照訪問用戶的ip哈希值來路由web-server，只要用戶的ip分佈是均勻的，請求理論上也是均勻的，ip哈希均衡方法可以做到，同一個用戶的請求固定落到同一臺web-server上，此策略適合有狀態服務，例如session(58沈劍備註：可以這麼做，但強烈不建議這麼做，站點層無狀態是分佈式架構設計的基本原則之一，session最好放到數據層存儲)
4)…
【站點層->服務層】的負載均衡
【站點層】到【服務層】的負載均衡，是通過“服務連接池”實現的。
上游連接池會建立與下游服務多個連接，每次請求會“隨機”選取連接來訪問下游服務。
上一篇文章《RPC-client實現細節》中有詳細的負載均衡、故障轉移、超時處理的細節描述，歡迎點擊link查閱，此處不再展開。
【數據層】的負載均衡
在數據量很大的情況下，由於數據層(db，cache)涉及數據的水平切分，所以數據層的負載均衡更爲複雜一些，它分爲“數據的均衡”，與“請求的均衡”。
數據的均衡是指：水平切分後的每個服務(db，cache)，數據量是差不多的。
請求的均衡是指：水平切分後的每個服務(db，cache)，請求量是差不多的。
業內常見的水平切分方式有這麼幾種：
一、按照range水平切分
每一個數據服務，存儲一定範圍的數據，上圖爲例：
user0服務，存儲uid範圍1-1kw
user1服務，存儲uid範圍1kw-2kw
這個方案的好處是：
(1)規則簡單，service只需判斷一下uid範圍就能路由到對應的存儲服務
(2)數據均衡性較好
(3)比較容易擴展，可以隨時加一個uid[2kw,3kw]的數據服務
不足是：
(1)請求的負載不一定均衡，一般來說，新註冊的用戶會比老用戶更活躍，大range的服務請求壓力會更大
二、按照id哈希水平切分
每一個數據服務，存儲某個key值hash後的部分數據，上圖爲例：
user0服務，存儲偶數uid數據
user1服務，存儲奇數uid數據
這個方案的好處是：
(1)規則簡單，service只需對uid進行hash能路由到對應的存儲服務
(2)數據均衡性較好
(3)請求均勻性較好
不足是：
(1)不容易擴展，擴展一個數據服務，hash方法改變時候，可能需要進行數據遷移
總結
負載均衡(Load Balance)是分佈式系統架構設計中必須考慮的因素之一，它通常是指，將請求/數據【均勻】分攤到多個操作單元上執行，負載均衡的關鍵在於【均勻】。
(1)【客戶端層】到【反向代理層】的負載均衡，是通過“DNS輪詢”實現的
(2)【反向代理層】到【站點層】的負載均衡，是通過“nginx”實現的
(3)【站點層】到【服務層】的負載均衡，是通過“服務連接池”實現的
(4)【數據層】的負載均衡，要考慮“數據的均衡”與“請求的均衡”兩個點，常見的方式有“按照範圍水平切分”與“hash水平切分”
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
負載均衡算法介紹：
輪詢調度
以輪詢的方式依次請求調度不同的服務器；實現時，一般爲服務器帶上權重；這樣有兩個好處：
- 針對服務器的性能差異可分配不同的負載；
- 當需要將某個結點剔除時，只需要將其權重設置爲0即可；
優點：實現簡單、高效；易水平擴展；
缺點：請求到目的結點的不確定，造成其無法適用於有寫的場景（緩存，數據庫寫）
應用場景：數據庫或應用服務層中只有讀的場景；
隨機方式
請求隨機分佈到各個結點；在數據足夠大的場景能達到一個均衡分佈；
優點：實現簡單、易水平擴展；
缺點：同Round Robin，無法用於有寫的場景；
應用場景：數據庫負載均衡，也是隻有讀的場景；
哈希：
根據key來計算需要落在的結點上，可以保證一個同一個鍵一定落在相同的服務器上；
優點：相同key一定落在同一個結點上，這樣就可用於有寫有讀的緩存場景；
缺點：在某個結點故障後，會導致哈希鍵重新分佈，造成命中率大幅度下降；
解決：一致性哈希 or 使用keepalived保證任何一個結點的高可用性，故障後會有其它結點頂上來；
應用場景：緩存，有讀有寫；
一致性哈希：
在服務器一個結點出現故障時，受影響的只有這個結點上的key，最大程度的保證命中率；
如twemproxy中的ketama方案；
生產實現中還可以規劃指定子key哈希，從而保證局部相似特徵的鍵能分佈在同一個服務器上；
優點：結點故障後命中率下降有限；
應用場景：緩存；
根據鍵的範圍來負載：
根據鍵的範圍來負載，前1億個鍵都存放到第一個服務器，1~2億在第二個結點；
優點：水平擴展容易，存儲不夠用時，加服務器存放後續新增數據；
缺點：負載不均；數據庫的分佈不均衡；（數據有冷熱區分，一般最近註冊的用戶更加活躍，這樣造成後續的服務器非常繁忙，而前期的結點空閒很多）
適用場景：數據庫分片負載均衡；
根據鍵對服務器結點數取模來負載：
根據鍵對服務器結點數取模來負載；比如有4臺服務器，key取模爲0的落在第一個結點，1落在第二個結點上。
優點：數據冷熱分佈均衡，數據庫結點負載均衡分佈；
缺點：水平擴展較難；
適用場景：數據庫分片負載均衡；
純動態結點負載均衡：
根據CPU、IO、網絡的處理能力來決策接下來的請求如何調度；
優點：充分利用服務器的資源，保證個結點上負載處理均衡；
缺點：實現起來複雜，真實使用較少；
不用主動負載均衡：
使用消息隊列轉爲異步模型，將負載均衡的問題消滅
負載均衡是一種推模型，一直向你發數據，那麼，將所有的用戶請求發到消息隊列中，所有的下游結點誰空閒，誰上來取數據處理；轉爲拉模型之後，消息了負載的問題；
優點：通過消息隊列的緩衝，保護後端系統，請求劇增時不會沖垮後端服務器；
水平擴展容易，加入新結點後，直接取queue即可；
缺點：不具有實時性；
應用場景：不需要實時返回的場景；
比如，12036下訂單後，立刻返回提示信息：您的訂單進去排隊了…等處理完畢後，再異步通知；