Lvs+keepalived+nginx+php的session 保持的算法

●什麼是會話保持，有什麼做用

會話保持是指在負載均衡器上有一種機制，在做負載均衡的同時，還保證同一用戶相關連的訪問請求會被分配到同一臺服務器上。

會話保持有什麼做用呢，舉例說明一下

若是有一個用戶訪問請求被分配到服務器A，而且在服務器A登陸了，而且在很短的時間，這個用戶又發出了一個請求，若是沒有會話保持功能的話，這個用戶的請求頗有可能會被分配到服務器B去，這個時候在服務器B上是沒有登陸的，因此你要從新登陸，可是用戶並不知道本身的請求被分配到了哪裏，用戶的感受就是登陸了，怎麼又要登陸，用戶體驗很很差。

 

●nginx 的 upstream目前支持 4 種方式的分配
1)、輪詢（默認）
      每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除。
2)、weight
      指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。
2)、ip_hash
      每一個請求按訪問ip的hash結果分配，這樣每一個訪客固定訪問一個後端服務器，能夠解決session的問題。  
3)、fair（第三方）

      按後端服務器的響應時間來分配請求，響應時間短的優先分配。

4)、url_hash（第三方）

 

● 服務器負載均衡算法有不少，包括輪循算法、最少鏈接算法、響應時間算法、散列算法、最少鏈接失誤算法，鏈路帶寬算法等等。

非持續性算法：

     一個客戶端的不一樣的請求可能被分配到一個實際服務組中的不一樣的實服務器上進行處理。主要有輪循算法、最少鏈接算法、響應速度算法等。

1>輪循算法（Round Robin）：

說明：每一次來自網絡的請求輪流分配給內部中的每臺服務器，從1至N而後從新開始。

舉例：此種均衡算法適合於服務器組中的全部服務器都有相同的軟硬件配置而且平均服務請求相對均衡的狀況；

 

2>最少鏈接算法（Least Connection）：

說明： 客戶端的每一次請求服務在服務器停留的時間均可能會有較大的差別，隨着工做時間的加長，若是採用簡單的輪循或隨機均衡算法，每一臺服務器上的鏈接進程可能會產生極大的不一樣，這樣的結果並不會達到真正的負載均衡。最少鏈接數均衡算法對內部中有負載的每一臺服務器都有一個數據記錄，記錄的內容是當前該服務器正在處理的鏈接數量，當有新的服務鏈接請求時，將把當前請求分配給鏈接數最少的服務器，使均衡更加符合實際狀況，負載更加均衡。

舉例：此種均衡算法適合長時間處理的請求服務。

 

3>響應速度算法（Response Time）：

說明： 負載均衡設備對內部各服務器發出一個探測請求（例如Ping），而後根據內部中各服務器對探測請求的最快響應時間來決定哪一臺服務器來響應客戶端的服務請求。

舉例:   

此種均衡算法能較好地反映服務器的當前運行狀態，但最快響應時間僅僅指的是負載均衡設備與服務器間的最快響應時間，而不是客戶端與服務器間的最快響應時間。

 

持續性算法：

     從一個特定的客戶端發出的請求都被分配到一個實服務組中的同一個實服務器上進行處理。主要包括：

A．基於IP的算法

－Persistent IP (pi)：基於用戶IP地址來選擇服務器。

－Hash IP (hi) ：基於用戶IP地址的HASH值，來選擇服務器

－Consistent Hash IP (chi)：

B．基於報頭/請求的算法

－Hash Header (hh)：基於用戶請求報中HTTP報頭來選擇服務器；

－Persistent Hostname (ph) ：基於用戶請求報中HTTP報頭的Hostname的HASH值，來選擇服務器；

－Persistent URL (pu)：基於對URI Tag 和值的靜態對應關係來選擇服務器。

－SSL Session ID (sslsid)：基於SSL會話ID來選擇服務器。

C．基於Cookie的算法

－Persistent Cookie (pc) ： 選擇服務器基於用戶請求包用Cookie Name / Value 的靜態對應關係；

－Hash Cookie (hc) ：選擇服務器基於用戶請求包用Cookie Name / Value 的Hash 值對應關係；

－Insert Cookie (ic) ：選擇服務器基於負載均衡器 向服務器響應包中插入Cookie；

－Re-write Cookie (rc)：選擇服務器基於負載均衡器向服務器響應包中重寫Cookie值。（必須爲重寫指定Cookie值的偏移量）

● 經過KeepAlived 來實現Nginx 負載均衡的雙機熱備。正常狀況下，兩臺Nginx 負載均衡服務器所有處於活動狀態，對外提供服務。經過兩臺服務器之間的互相檢測機制，當主服務器上的檢測程序發現自身的Nginx 沒法訪問時，中止綁定虛擬IP，改由備用服務器綁定虛擬IP，同時由主服務器給網關發送Arping 包，保證了網關上IP、MAC 地址對應關係可以立刻更改，可以作到強行接管虛擬IP。

 

●LVS[F5]負載均衡的八種調度算法

負載均衡算法1.輪叫調度(Round Robin)

調度器經過「輪叫"調度算法將外部請求按順序輪流分配到集羣中的真實服務器上,它均等地對待每一臺服務器,而無論服務器上實際的鏈接數和系統負載｡

負載均衡算法2.加權輪叫(Weighted Round Robin)

調度器經過「加權輪叫"調度算法根據真實服務器的不一樣處理能力來調度訪問請求｡這樣能夠保證處理能力強的服務器能處理更多的訪問流量｡調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值｡

負載均衡算法3.最少連接(Least Connections)

調度器經過「最少鏈接"調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上｡若是集羣系統的真實服務器具備相近的系統性能,採用「最小鏈接"調度算法能夠較好地均衡負載｡

負載均衡算法4.加權最少連接(Weighted Least Connections)

在集羣系統中的服務器性能差別較大的狀況下,調度器採用「加權最少連接"調度算法優化負載均衡性能,具備較高權值的服務器將承受較大比例的活動鏈接負載｡調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值｡

負載均衡算法5.基於局部性的最少連接(Locality-Based Least Connections)

「基於局部性的最少連接"調度算法是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統｡該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器,若該服務器是可用的且沒有超載,將請求發送到該服務器;若服務器不存在,或者該服務器超載且有服務器處於一半的工做負載,則用「最少連接"的原則選出一個可用的服務器,將請求發送到該服務器｡

負載均衡算法6.帶複製的基於局部性最少連接(Locality-Based Least Connections with Replication)

「帶複製的基於局部性最少連接"調度算法也是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統｡它與LBLC算法的不一樣之處是它要維護從一個目標IP地址到一組服務器的映射,而LBLC算法維護從一個目標IP地址到一臺服務器的映射｡該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組,按「最小鏈接"原則從服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器;若服務器超載,則按「最小鏈接"原則從這個集羣中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器｡同時,當該服務器組有一段時間沒有被修改,將最忙的服務器從服務器組中刪除,以下降複製的程度｡

負載均衡算法7.目標地址散列(Destination Hashing)

「目標地址散列"調度算法根據請求的目標IP地址,做爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空｡

負載均衡算法8.源地址散列(Source Hashing)

「源地址散列"調度算法根據請求的源IP地址,做爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空｡

瞭解這些算法原理可以在特定的應用場合選擇最適合的調度算法,從而儘量地保持Real Server的最佳利用性｡固然也能夠自行開發算法,不過這已超出本文範圍,請參考有關算法原理的資料｡

 

● keepalived是LVS集羣節點健康檢測的一個用戶空間守護進程，也是LVS的引導故障轉移模塊（director failover）。Keepalived守護進程能夠檢查LVS池的狀態。若是LVS服務器池當中的某一個服務器宕機了。keepalived會經過一個setsockopt呼叫通知內核將這個節點從LVS拓撲圖中移除。