lvs scheduler:
根據其調度時是否考慮后端主機的當前負載，可分為靜態方法和動態方法
靜態方法：僅根據算法本身進行調度：
RR:Round Ronin 輪詢
WRR:Weighted Round Ronin 加權輪詢
SH:Source Hash 將客戶端的源IP和調度后的RS轉換為hash值（key/value），保存在Director的會話表中，下一次連接時直接查找會話表進行轉發，而不需要重新調度
在用戶使用NAT上網時，因一內網中不同用戶使用的源IP都是NAT后的某個IP，SH的調度方式很粗糙（LVS無法基于COOKIE做負載均衡）
DH:Destination Hash 將客戶端請求的目標地址和調度后的RS轉換為hash至，保存在Director的會話表中，下一次連接時直接查找會話表進行轉發，而不需要重新調度
通常用在正向web代理（緩存），負載均衡內網用戶對外部服務器的請求
哈希的是目標地址
動態方法：根據算法及各RS當前的負載狀態進行調度
Overhead:RS當前的負載值
Overhead相同的情況下，按可用RS列表進行輪詢
LC：least connections,最少連接
Overhead=Active*256+Inactive （活動連接*256+非活動連接） 非活動連接即服務器等待客戶端發送請求，而客戶端并不發送
根據各RS的Overhead選擇負載最小的服務器
WLC：Weighted LC 加權最小連接
Overhead=(Active*256+Inactive)/weight
SED：Shortest Expections Delay 主要用于解決在空閑狀態下，連接能夠被分配至權重最大的服務器
Overhead=(Active+1)*256/weight
NQ：Nerver Queue 優先保證每臺服務器上均分配到連接，之后根據Overhead值進行分配
LBLC：Locallity-Based LC 基于本地的最少連接
動態DH算法：對同一個目前請求進行動態的負載均衡，損失命中率而提高了均衡性
LBLCR：LBLC算法的改進，如在各web緩存RS服務器上可以相互同步緩存數據
帶復制功能的LBLC
WLC動態算法是最為通常，而且是默認的動態算法
負載均衡集群中保持會話一致的方式：
（1）源地址哈希；
（2）會話集群：適用于小規模RS集群場景，將多臺RS組件一個Seesion cluster，保證每臺服務器上的會話內容都一致
（3）會話服務器：創建一個共享存儲用于保持會話數據（需要支持KV類型的數據庫，如redis、hbase等）
原創文章，作者：oranix，如若轉載，請注明出處：http://www.www58058.com/66284
