ipvs scheduler

ipvs scheduler：根據其排程時是否考慮各RS當前的負載狀態
兩種：靜態方法和動態方法
靜態方法：僅根據演算法本身進行排程
1、RR：roundrobin，輪詢

2、WRR：Weighted RR，加權輪詢

3、SH：Source Hashing，實現session sticky，源IP地址hash；將來自於同一個IP地址的請求始終發往第一次挑中的RS，從而實現會話繫結 #根據ip來固定，傳輸層；而cookie不支援，應用層

4、DH：Destination Hashing；目標地址雜湊，將發往同一個目標地址的請求 始終轉發至第一次挑中的RS，典型使用場景是正向代理快取場景中的負載均衡， 如：寬頻運營商

動態方法：主要根據每RS當前的負載狀態及排程演算法進行排程Overhead=value 較小的RS將被排程
1、LC：least connections 適用於長連線應用 #最小連線數
Overhead=activeconns*256+inactiveconns

2、WLC：Weighted LC，預設排程方法 #帶權重的最少連線數，當連線數為0時，則wlc演算法失效
Overhead=(activeconns*256+inactiveconns)/weight

3、SED：Shortest Expection Delay,初始連線高權重優先 #解決wlc連線數為0時的問題，但初始連線均向權重高的伺服器上連線，也不太合適

4、NQ：Never Queue，第一輪均勻分配，後續SED #解決SED初始連線偏重於權重高的伺服器連線問題

5、LBLC：Locality-Based LC，動態的DH演算法，使用場景：根據負載狀態實現正向代理

6、LBLCR：LBLC with Replication，帶複製功能的LBLC，解決LBLC負載不均衡問題，從負載重的複製到負載輕的RS

ngx_http_upstream_module

即nginx做反向代理模組

upstream name { … }
定義後端伺服器組，會引入一個新的上下文
預設排程演算法是wrr #rr
Context: http
upstream httpdsrvs {
server …
server… …
}

演算法總結
1、rr
2、wrr
3、ip_hash 源地址hash排程方法
4、least_conn 最少連線排程演算法，當server擁有不同的權重時其為wlc，當所有後端主機連線數相同時，則使用wrr，適用於長連線，
5、hash key [consistent] 基於指定的key的hash表來實現對請求的排程， 此處的key可以直接文字、變數或二者組合
作用：將請求分類，同一類請求將發往同一個upstream server，使用consistent引數，將使用ketama一致性hash演算法，適用於後端是Cache伺服器 （如varnish）時使用

haproxy

http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-balance
balance

roundrobin 
static-rr
leastconn
first
source
uri 
url_param
hdr(<name>)   如hdr(user-agent)
rdp-cookie
rdp-cookie(<name>)

http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-hash-type
hash-type：雜湊演算法

 hash-type <method> <function> <modifier>
        method：
              map-based：除權取餘法，雜湊資料結構是靜態陣列  
              consistent：一致性雜湊，雜湊資料結構是一棵樹  
        function : 雜湊函式，取值：sdbm，djb2，wt6  
        modifier： 取值avalanche時，將修改雜湊值，而非直接使用 
  default_backend <backend>
        無use_backend 匹配時，使用預設的backend，用於frontend中 
  default-server [param*]
        為backend中的各server設定預設選項 

tomcat 的http前端做排程

[[email protected] ~ ]#httpd -M 參見35.1tomcat實驗
lbmethod_bybusyness_module (shared) #類似lc(least connection)
lbmethod_byrequests_module (shared) #類似輪詢roundrobin
lbmethod_bytraffic_module (shared) #根據鏈路流量排程
lbmethod_heartbeat_module (shared)

一致性hash

百度百科
一致性hash起源於解決路由問題；而keepalived高可用性使用的vrrp，亦來源於H3C中的vrrp協議

H3C中路由vrrp協議如下
VRRP是一種容錯協議，它保證當主機的下一跳路由器出現故障時，由另一臺路由 器來代替出現故障的路由器進行工作，從而保持網路通訊的連續性和可靠性。
VRRP具有如下優點：
z 簡化網路管理。在具有多播或廣播能力的區域網（如乙太網）中，藉助VRRP 能在某臺裝置出現故障時仍然提供高可靠的預設鏈路，有效避免單一鏈路發生故障後網路中斷的問題，而無需修改動態路由協議、路由發現協議等配置資訊，也無需修改主機的預設閘道器配置。
z 適應性強。VRRP 報文封裝在 IP 報文中，支援各種上層協議。
z 網路開銷小。VRRP 只定義了一種報文——VRRP 通告報文，並且只有處於 Master 狀態的路由器可以傳送 VRRP 報文。

一致性hash簡單說明
需求描述
在企業部署叢集時，為了提供使用者體驗，減輕後端伺服器壓力等因素考量，往往會部署快取伺服器，如varnish作為圖片快取，memcache作為資料庫快取等。如果拿web伺服器上的圖片來說，快取到快取伺服器中，當上萬用戶訪問時，圖片如何快取，如何查詢等問題，需要解決，按照目前技術，一般都是hash(鍵)，即用hash演算法對一個鍵值對中的鍵做運算，此結果由於hash演算法的特性決定了其唯一性，通過hash對鍵或者關鍵字做運算，實現需求目的，如nginx做反向代理時的hash key中的引數consistent。但在對大量圖片hash運算後放到快取伺服器，一般採用hash(key)mod(p),p為一個數值，如快取伺服器的數量，當快取伺服器的數量為3時，如圖1，假設均勻分佈：

但使用上述hash演算法時，是假設的理想狀態，即對3臺伺服器取模，才能均勻分佈在hash環上，但3臺快取伺服器一旦有一臺宕機時或者新增快取伺服器時，則直接導致hash(key)mod(3)變為hash(key)mod(2)，導致快取的圖片對應的伺服器號碼發生變化，引起伺服器大量快取不可用，客戶需要從新去後端伺服器請求圖片，且快取伺服器從新快取圖片(需要計算)，導致後臺伺服器壓力驟增，而剩餘的快取伺服器也面臨著效能的考驗。在這種情況下，意外發生的可能性比較大，如後臺伺服器宕機，正常快取伺服器宕機，導致無法為使用者提供服務。顯然，這種解決思路並不完善

提出一致性hash演算法解決問題的基本概念
經過科學家的努力，實際一致性hash演算法採用取模的方法，只是其模為2的32次方，即hash(key)mod(2^32),這樣一來，由於2^32次方數值較大，在實際中hash(key)moe(2^32)時，可以解決快取伺服器數量增加或者減少帶來快取圖片失效的問題，即快取伺服器的數量相比於2^32，一個天上，一個地下，相差太大，故而，上述問題當宕機一臺快取伺服器時，或者新增快取伺服器時，由於演算法決定，影響的只是較少的快取付伺服器上的圖片快取失效，如圖2
相比於圖1的結果：為0放在快取伺服器1上；為1放在快取伺服器2上，為2放在快取伺服器3上的各自區間，0到2^32-1結果：0到2^32-1/3的結果放在快取伺服器1的區間等，自然快取伺服器數量變化對整體影響較小;

缺點：hash換偏斜
圖中均是把快取伺服器均勻對映在hash換上，如果如圖3,3個快取伺服器被對映在hash環比較集中的地方，則按照順時針方向快取圖片，伺服器1將快取大量圖片，顯然不合理

虛擬節點
解決hash換偏斜問題，即(hash(key)+10000)mod(2^32)