負載均衡調度演算法

① keepalived怎麼重新載入配置文件

keepalived.conf內容說明如下

●全局定義塊
1、email通知。作用：有故障，發郵件報警。
2、Lvs負載均衡器標識（lvs_id）。在一個網路內，它應該是唯一的。
3、花括弧「{}」。用來分隔定義塊，因此必須成對出現。如果寫漏了，keepalived運行時，不會得到預期的結果。由於定義塊內存在嵌套關系，因此很容易遺漏結尾處的花括弧，這點要特別注意。
●VRRP定義塊
1、同步vrrp組vrrp_sync_group。作用：確定失敗切換（FailOver）包含的路由實例個數。即在有2個負載均衡器的場景，一旦某個負載均衡器失效，需要自動切換到另外一個負載均衡器的實例是哪些？
2、實例組group。至少包含一個vrrp實例。
3、Vrrp實例vrrp_instance。實例名出自實例組group所包含的那些名字。
(1) 實例狀態state。只有MASTER和BACKUP兩種狀態，並且需要大寫這些單詞。其中MASTER為工作狀態，BACKUP為備用狀態。當 MASTER所在的伺服器失效時，BACKUP所在的系統會自動把它的狀態有BACKUP變換成MASTER；當失效的MASTER所在的系統恢復 時，BACKUP從MASTER恢復到BACKUP狀態。
(2)通信介面interface。對外提供服務的網路介面，如eth0,eth1.當前主流的伺服器都有2個或2個以上的介面，在選擇服務介面時，一定要核實清楚。
(3)lvs_sync_daemon_inteface。 負載均衡器之間的監控介面，類似於HA HeartBeat的心跳線。但它的機制優於Heartbeat，因為它沒有「裂腦」這個問題，它是以優先順序這個 機制來規避這個麻煩的。在DR模式中，lvs_sync_daemon_inteface 與服務介面interface 使用同一個網路介面。
(4)虛擬路由標識virtual_router_id。這個標識是一個數字，並且同一個vrrp實例使用唯一的標識。即同一個vrrp_stance，MASTER和BACKUP的virtual_router_id是一致的，同時在整個vrrp內是唯一的。
(5)優先順序priority。這是一個數字，數值愈大，優先順序越高。在同一個vrrp_instance里，MASTER 的優先順序高於BACKUP。若MASTER的priority值為150，那麼BACKUP的priority只能是140或更小的數值。
(6)同步通知間隔advert_int。MASTER與BACKUP負載均衡器之間同步檢查的時間間隔，單位為秒。
(7)驗證authentication。包含驗證類型和驗證密碼。類型主要有PASS、AH兩種，通常使用的類型為PASS，據說AH使用時有問題。驗證密碼為明文，同一vrrp實例MASTER與BACKUP 使用相同的密碼才能正常通信。
4、 虛擬ip地址virtual_ipaddress。可以有多個地址，每個地址佔一行，不需要指定子網掩碼。注意：這個ip必須與我們在lvs客戶端設定的vip相一致！
●虛擬伺服器virtual_server定義塊
虛擬伺服器定義是keepalived框架最重要的項目了，是keepalived.conf必不可少的部分。
1、虛擬伺服器virtual_server。這個ip來自於vrrp定義塊的第「4」步，後面一個空格，然後加上埠號。定義一個vip，可以實現多個tcp埠的負載均衡功能。
(1)delay_loop。健康檢查時間間隔，單位是秒。
(2)lb_algo。負載均衡調度演算法，互聯網應用常使用wlc或rr。
(3)lb_kind。負載均衡轉發規則。一般包括DR、NAT、TUN3種，在我的方案中，都使用DR的方式。
(4)persistence_timeout。 會話保持時間，單位是秒。這個選項對動態網站很有用處：當用戶從遠程用帳號進行登陸網站時，有了這個會話保持功能，就能把用戶的請求轉發給同一個應用服務 器。在這里，我們來做一個假設，假定現在有一個lvs 環境，使用DR轉發模式，真實伺服器有3個， 負載均衡器不啟用會話保持功能。當用戶第一次訪問的時候，他的訪問請求被負載均衡器轉給某個真實伺服器，這樣他看到一個登陸頁面，第一次訪問完畢；接著他 在登陸框填寫用戶名和密碼，然後提交；這時候，問題就可能出現了---登陸不能成功。因為沒有會話保持，負載均衡器可能會把第2次的請求轉發到其他的伺服器。
(5)轉發協議protocol。一般有tcp和udp兩種。實話說，我還沒嘗試過udp協議類的轉發。
2、真實伺服器real_server，也即伺服器池。Real_server的值包括ip地址和埠號，多個連續的真實ip。
(1)權重weight，權重值是一個數字，數值越大，權重越高。使用不同的權重值的目的在於為不同性能的機器分配不同的負載，性能較好的機器，負載分擔大些；反之，性能差的機器，則分擔較少的負載，這樣就可以合理的利用不同性能的機器資源。
(2)Tcp檢查tcp_check。

第③版更新內容如下:
每台伺服器都有二塊網卡，分別連接內外網；後端的mysql資料庫與web連接採用內網方式，整個網路環境採用內網；
增加了keepalived.conf語法內容；
刪除了lvs.sh腳本內容，直接讓keepalived內容更直接明了；
lvs主從機上的keepalived.conf文件我直接從生產伺服器上download下來了，可方便大家使用。

※值得注意的是：
1、你必須向你的伺服器所在機房IDC多申請一個IP供VIP使用；多關注/var/log/messages和ipvsadm -ln，利用其有效信息排錯。
2、伺服器的iptables、Selinux均關閉；在生產環境中，我就遇到了iptables的NAT轉發問題，導致了lvs失敗。
3、 keepalived的啟動過程並不會對配置文件進行語法檢查，就算沒有配置文件，keepalived的守護進程照樣能夠被運行起來。在默認狀態下，即 不指定配置文件的位置--keepalived先查找文件/etc/keepalived/keepalived.conf。
4、session的過程默認是以文件的形式存在，在瀏覽器關閉或重啟時刪除；會話保持我建議寫成120秒，如果這個值設置得不合理，用戶將得到非常糟糕的訪問效果。
5、 keepalived是lvs的擴展項目，因此它們之間具備良好的兼容性，這點應該是keepalived部署比其他類似工具能更簡潔的原因 吧，lvs+keepalived目前是一個應用於生產環境的成熟架構，實現了真正意義上的負載均衡高可用，尤其適用於bbs和blog(它們均是訪問頻 繁，用戶量大的對象)，建議熟練掌握。

LVS 演算法說明

LVS的常見八種調度演算法：
一:輪叫調度（Round-Robin Scheling）

輪叫調度（Round Robin Scheling）演算法就是以輪叫的方式依次將請求調度不同的伺服器，即每次調度執行i = (i + 1) mod n，並選出第i台伺服器。演算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。

二:加權輪叫調度（Weighted Round-Robin Scheling）

加權輪叫調度 （Weighted Round-Robin Scheling）演算法可以解決伺服器間性能不一的情況，它用相應的權值表示伺服器的處理性能，伺服器的預設權值為1。假設伺服器A的權值為1，B的權值為2，則表示伺服器B的處理性能是A的兩倍。加權輪叫調度演算法是按權值的高低和輪叫方式分配請求到各伺服器。權值高的伺服器先收到的連接，權值高的伺服器比權值低的伺服器處理更多的連接，相同權值的伺服器處理相同數目的連接數。

三:最小連接調度（Least-Connection Scheling）

最 小連接調度（Least- Connection Scheling）演算法是把新的連接請求分配到當前連接數最小的伺服器。最小連接調度是一種動態調 度演算法，它通過伺服器當前所活躍的連接數來估計伺服器的負載情況。調度器需要記錄各個伺服器已建立連接的數目，當一個請求被調度到某台伺服器，其連接數加1；當連接中止或超時，其連接數減一。
四:加權最小連接調度（Weighted Least-Connection Scheling）

加權最小連接調 度（Weighted Least-Connection Scheling）演算法是最小連接調度的超集，各個伺服器用相應的權值表示其處理性能。伺服器的預設權值為1，系統管理員可以動態地設置伺服器的權值。加權最小連接調度在調度新連接時盡可能使伺服器的已建立連接數和其權值成比例。

五:基於局部性的最少鏈接（Locality-Based Least Connections Scheling）

基 於局部性的最少鏈接調度（Locality-Based Least Connections Scheling，以下簡稱為LBLC）演算法是針對請 求報文的目標IP地址的負載均衡調度，目前主要用於Cache集群系統，因為在Cache集群中客戶請求報文的目標IP地址是變化的。這里假設任何後端服 務器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一台伺服器，來提高各台伺服器的訪問局部性和 主存Cache命中率，從而整個集群系統的處理能力。LBLC調度演算法先根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的 且沒有超載，將請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於其一半的工作負載，則用「最少鏈接」的原則選出一個可用的伺服器，將 請求發送到該伺服器。

六: 帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication Scheling）

帶 復制的基於局部性最少鏈接調度（Locality- Based Least Connections with Replication Scheling，以下簡稱為LBLCR）演算法也是針對目標 IP地址的負載均衡，目前主要用於Cache集群系統。它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組伺服器的映射，而LBLC演算法維護 從一個目標IP地址到一台伺服器的映射。對於一個「熱門」站點的服務請求，一台Cache 伺服器可能會忙不過來處理這些請求。這時，LBLC調度演算法會 從所有的Cache伺服器中按「最小連接」原則選出一台Cache伺服器，映射該「熱門」站點到這台Cache伺服器，很快這台Cache伺服器也會超 載，就會重復上述過程選出新的Cache伺服器。這樣，可能會導致該「熱門」站點的映像會出現在所有的Cache伺服器上，降低了Cache伺服器的使用 效率。LBLCR調度演算法將「熱門」站點映射到一組Cache伺服器（伺服器集合），當該「熱門」站點的請求負載增加時，會增加集合里的Cache服務 器，來處理不斷增長的負載；當該「熱門」站點的請求負載降低時，會減少集合里的Cache伺服器數目。這樣，該「熱門」站點的映像不太可能出現在所有的 Cache伺服器上，從而提供Cache集群系統的使用效率。LBLCR演算法先根據請求的目標IP 地址找出該目標IP地址對應的伺服器組；按「最小連 接」原則從該伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載；則按 「最小連接」原則從整個集群中選出一台伺服器，將 該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低復制的程度。

七:目標地址散列調度（Destination Hashing Scheling）

目 標地址散列調度 （Destination Hashing Scheling）演算法也是針對目標IP地址的負載均衡，但它是一種靜態映射演算法，通過 一個散列（Hash）函數將一個目標IP地址映射到一台伺服器。目標地址散列調度演算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分 配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

八:源地址散列調度（Source Hashing Scheling）

源 地址散列調度（Source Hashing Scheling）演算法正好與目標地址散列調度演算法相反，它根據請求的源IP地址，作為散列鍵 （Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。它採用的散列函數與目標地址 散列調度演算法的相同。它的演算法流程與目標地址散列調度演算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址，所以這里不一一敘述。在實際應用 中，源地址散列調度和目標地址散列調度可以結合使用在防火牆集群中，它們可以保證整個系統的唯一出入口。

此文出處撫琴煮酒之網路博客

② 常見的負載均衡技術

四層負責均衡：主要是指通過判斷報文的IP地址和埠並通過一定的負載均衡演算法來決定轉發到哪個指定目標，主要工作在OSI模型的第四層。四層負載均衡對數據包只是起一個數據轉發的作用，並不會干預客戶端與伺服器之間應用層的通信（如：三次握手等）。所以能對數據所進行的操作也就很少，但相對於七層負載均衡來講效率會高上很多

七層負載均衡：也被稱為「內容交換」，指的是負載均衡設備通過報文中的應用層信息(URL、HTTP頭部等信息)和負載均衡演算法，選擇到達目的的內部伺服器。七層負載均衡可以「智能化」地篩選報文中 應用層信息，然後根據不同的信息進行特定的負載均衡調度。這種方式提升了應用系統在網路層上的靈活性，另外也在一定程度上提升了後端系統的安全性。因為像網路常見的DoS攻擊，這些攻擊在七層負載均衡的環境下通常都在負載均衡設備上就截止了，不會影響到後台伺服器的正常運行。

前網路中常見的負載均衡主要分為硬體負載均衡和軟體負載均衡。硬體負載均衡比較知名的產品有F5 Big-IP、Cirtix Netscaler等等。而軟體負載均衡就有著眾多的開源項目，常見的有Haproxy、nginx、lvs等。
Haproxy：

lvs:

nginx:

Haproxy可以做代理服務相對於nginx而言有很多相同之處，統一可以基於mode tcp進行四層代理也可以基於mode http進行七層代理，但不同的是其無法使用location和if等進行匹配判斷。突出優勢在於有會話綁定，web管理界面，狀態統計非常詳細。官方推薦只啟用一個進程，相對於nginx多進程架構工作並不理想，更多的線程可能會受到系統內存的一些限制。
程序環境：
主程序：/usr/sbin/haproxy
主配置文件：/etc/haproxy/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service

查看配置文件

重要的幾個參數，及性能調優，多數無需修改

發現日誌發送給本機rsyslog的local2的facility，而本機的rsyslog里並沒有定義，需要我們自己去配置
所以vim /etc/rsyslog.conf添加一段將local2的所有信息記錄在對應日誌文件中

由於HAProxy可以工作在七層模型下，因此，要實現HAProxy的強大功能，一定要使用強大靈活的ACL規則，通過ACL規則可以實現基於HAProxy的智能負載均衡系統。HAProxy通過ACL規則完成兩種主要的功能，分別是：
1）通過設置的ACL規則檢查客戶端請求是否合法。如果符合ACL規則要求，那麼將放行；如果不符合規則，則直接中斷請求。
2）符合ACL規則要求的請求將被提交到後端的backend伺服器集群，進而實現基於ACL規則的負載均衡。HAProxy中的ACL規則經常使用在frontend段中，使用方法如下：
acl 自定義的acl 名稱 acl 方法 -i [ 匹配的路徑或文件] 其中：
·acl：是一個關鍵字，表示定義ACL規則的開始。後面需要跟上自定義的ACL名稱。
·acl方法：這個欄位用來定義實現ACL的方法，HAProxy定義了很多ACL方法，經常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。
·-i：表示不區分大小寫，後面需要跟上匹配的路徑或文件或正則表達式。與ACL規則一起使用的HAProxy參數還有use_backend，use_backend後面需要跟上一個backend實例名，表示在滿足ACL規則後去請求哪個backend實例，與use_backend對應的還有default_backend參數，它表示在沒有滿足ACL條件的時候默認使用哪個後端

這些例子定義了www_policy、bbs_policy、url_policy三個ACL規則，第一條規則表示如果客戶端以 www.z.cn 或 z.cn 開頭的域名發送請求時，則此規則返回true，同理第二條規則表示如果客戶端通過 bbs.z.cn 域名發送請求時，則此規則返回true，而第三條規則表示如果客戶端在請求的URL中包含「buy_sid=」字元串時，則此規則返回true。
第四、第五、第六條規則定義了當www_policy、bbs_policy、url_policy三個ACL規則返回true時要調度到哪個後端backend，例如，當用戶的請求滿足www_policy規則時，那麼HAProxy會將用戶的請求直接發往名為server_www的後端backend，其他以此類推。而當用戶的請求不滿足任何一個ACL規則時，HAProxy就會把請求發往由default_backend選項指定的server_cache這個後端backend。

與上面的例子類似，本例中也定義了url_static、host_www和host_static三個ACL規則，其中，第一條規則通過path_end參數定義了如果客戶端在請求的URL中以.gif、.png、.jpg、.css或.js結尾時返回true，第二條規則通過hdr_beg（host）參數定義了如果客戶端以www開頭的域名發送請求時則返回true，同理，第三條規則也是通過hdr_beg（host）參數定義了如果客戶端以img.、video.、download.或ftp.開頭的域名發送請求時則返回true。
第四、第五條規則定義了當滿足ACL規則後要調度到哪個後端backend，例如，當用戶的請求同時滿足host_static規則與url_static規則，或同時滿足host_www和url_static規則時，那麼會將用戶請求直接發往名為static的後端backend，如果用戶請求滿足host_www規則，那麼請求將被調度到名為www的後端backend，如果不滿足所有規則，那麼將用戶請求默認調度到名為server_cache的這個後端backend。

log：全局的日誌配置，local0是日誌設備，info表示日誌級別。其中日誌級別有err、warning、info、debug4種可選。這個配置表示使用127.0.0.1上的rsyslog服務中的local0日誌設備，記錄日誌等級為info。

maxconn：設定每個HAProxy進程可接受的最大並發連接數，此選項等同於Linux命令行選項「ulimit -n」。

user/group：設置運行HAProxy進程的用戶和組，也可使用用戶和組的uid和gid值來替代。

daemon：設置HAProxy進程進入後台運行。這是推薦的運行模式。

nbproc：設置HAProxy啟動時可創建的進程數，此參數要求將HAProxy運行模式設置為daemon，默認只啟動一個進程。該值的設置應該小於伺服器的CPU核數。創建多個進程，能夠減少每個進程的任務隊列，但是過多的進程可能會導致進程崩潰。

pidfile：指定HAProxy進程的pid文件。啟動進程的用戶必須有訪問此文件的許可權。

mode：設置HAProxy實例默認的運行模式，有tcp、http、health三個可選值。

retries：設置連接後端伺服器的失敗重試次數，如果連接失敗的次數超過這里設置的值，HAProxy會將對應的後端伺服器標記為不可用。此參數也可在後面部分進行設置。

timeout connect：設置成功連接到一台伺服器的最長等待時間，默認單位是毫秒，但也可以使用其他的時間單位後綴。

timeout client：設置連接客戶端發送數據時最長等待時間，默認單位是毫秒，也可以使用其他的時間單位後綴。

timeout server：設置伺服器端回應客戶端數據發送的最長等待時間，默認單位是毫秒，也可以使用其他的時間單位後綴。

timeout check：設置對後端伺服器的檢測超時時間，默認單位是毫秒，也可以使用其他的時間單位後綴。

bind：此選項只能在frontend和listen部分進行定義，用於定義一個或幾個監聽的套接字。bind的使用格式為： bind [<address>:<port_range>] interface <interface>其可以為主機名或IP地址，如果將其設置為「*」或「0.0.0.0」，將監聽當前系統的所有IPv4地址。port_range可以是一個特定的TCP埠，也可是一個埠范圍，小於1024的埠需要有特定許可權的用戶才能使用。interface為可選選項，用來指定網路介面的名稱，只能在Linux系統上使用。

option httplog：在默認情況下，HAProxy日誌是不記錄HTTP請求的，這樣很不方便HAProxy問題的排查與監控。通過此選項可以啟用日誌記錄HTTP請求。

option forwardfor：如果後端伺服器需要獲得客戶端的真實IP，就需要配置此參數。由於HAProxy工作於反向代理模式，因此發往後端真實伺服器的請求中的客戶端IP均為HAProxy主機的IP，而非真正訪問客戶端的地址，這就導致真實伺服器端無法記錄客戶端真正請求來源的IP，而X-Forwarded-For則可用於解決此問題。通過使用forwardfor選項，HAProxy就可以向每個發往後端真實伺服器的請求添加X-Forwarded-For記錄，這樣後端真實伺服器日誌可以通過「X-Forwarded-For」信息來記錄客戶端來源IP。

option httpclose：此選項表示在客戶端和伺服器端完成一次連接請求後，HAProxy將主動關閉此TCP連接。這是對性能非常有幫助的一個參數。

log global：表示使用全局的日誌配置，這里的global表示引用在HAProxy配置文件global部分中定義的log選項配置格式。

default_backend：指定默認的後端伺服器池，也就是指定一組後端真實伺服器，而這些真實伺服器組將在backend段進行定義。這里的htmpool就是一個後端伺服器組。

option redispatch：此參數用於cookie保持的環境中。在默認情況下，HAProxy會將其請求的後端伺服器的serverID插入cookie中，以保證會話的session持久性。而如果後端的伺服器出現故障，客戶端的cookie是不會刷新的，這就會出現問題。此時，如果設置此參數，就會將客戶的請求強制定向到另外一台健康的後端伺服器上，以保證服務正常。

option abortonclose：如果設置了此參數，可以在伺服器負載很高的情況下，自動結束當前隊列中處理時間比較長的連接。
-balance：此關鍵字用來定義負載均衡演算法。目前HAProxy支持多種負載均衡演算法，常用的有如下幾種：

cookie：表示允許向cookie插入SERVERID，每台伺服器的SERVERID可在下面的server關鍵字中使用cookie關鍵字定義。

option httpchk：此選項表示啟用HTTP的服務狀態檢測功能。HAProxy作為一個專業的負載均衡器，它支持對backend部分指定的後端服務節點的健康檢查，以保證在後端backend中某個節點不能服務時，把從frotend端進來的客戶端請求分配至backend中其他健康節點上，從而保證整體服務的可用性。
option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各個參數的含義如下：

check：表示啟用對此後端伺服器執行健康狀態檢查。

inter：設置健康狀態檢查的時間間隔，單位為毫秒。

rise：設置從故障狀態轉換至正常狀態需要成功檢查的次數，例如，「rise 2」表示2次檢查正確就認為此伺服器可用。

fall：設置後端伺服器從正常狀態轉換為不可用狀態需要檢查的次數，例如，「fall 3」表示3次檢查失敗就認為此伺服器不可用。

cookie：為指定的後端伺服器設定cookie值，此處指定的值將在請求入站時被檢查，第一次為此值挑選的後端伺服器將在後續的請求中一直被選中，其目的在於實現持久連接的功能。上面的「cookie server1」表示web1的serverid為server1。同理，「cookie server2」表示web2的serverid為server2。

weight：設置後端真實伺服器的權重，默認為1，最大值為256。設置為0表示不參與負載均衡。

backup：設置後端真實伺服器的備份伺服器，僅僅在後端所有真實伺服器均不可用的情況下才啟用。

用nginx反代後端的兩台tomcat主機，做動靜分離，如果是jsp結尾的就發往後端，否則就交給nginx處理。
在兩台tomcat主機上創建應用

nginx配置

則動靜分離就實現了，並且我們還基於uri實現了會話粘性

③ 什麼是負載均衡有啥優缺點

一、什麼是負載均衡

負載均衡（Load Balance）其意思就是分攤到多個操作單元上進行執行，例如Web伺服器、FTP伺服器、企業關鍵應用伺服器和其它關鍵任務伺服器等，從而共同完成工作任務。

單從字面上的意思來理解就可以解釋N台伺服器平均分擔負載，不會因為某台伺服器負載高宕機而某台伺服器閑置的情況。那麼負載均衡的前提就是要有多台伺服器才能實現，也就是兩台以上即可。

負載均衡建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴展網路設備和伺服器的帶寬、增加吞吐量、加強網路數據處理能力、提高網路的靈活性和可用性。

二、負載均衡的優點

減少伺服器的壓力，將原本一台伺服器索要承受的訪問量分給多台，並提高項目的可用性，當一台伺服器掛掉的時候不會導致項目癱瘓。

三、四層負載均衡和七層負載均衡



四層負載均衡工作在OSI模型的傳輸層，主要工作是轉發，它在接收到客戶端的流量以後通過修改數據包的地址信息將流量轉發到應用伺服器。

七層負載均衡工作在OSI模型的應用層，因為它需要解析應用層流量，所以七層負載均衡在接到客戶端的流量以後，還需要一個完整的TCP/IP協議棧。七層負載均衡會與客戶端建立一條完整的連接並將應用層的請求流量解析出來，再按照調度演算法選擇一個應用伺服器，並與應用伺服器建立另外一條連接將請求發送過去，因此七層負載均衡的主要工作就是代理。 七層負載均衡 也稱為「內容交換」，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。

七層負載均衡的優點：這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改，極大的提升了應用系統在網路層的靈活性；安全性高。

④ U8伺服器參數配置中負載均衡如何設置

網路的負載均衡是一種動態均衡技術，通過一些工具實時地分析數據包，掌握網路中的數據流量狀況，把任務合理均衡地分配出去。這種技術基於現有網路結構，提供了一種擴展伺服器帶寬和增加伺服器吞吐量的廉價有效的方法，加強了網路數據處理能力，提高了網路的靈活性和可用性。

⑤ 多台異地伺服器如何實現負載均衡

一般用的就用簡單的輪詢就好了
調度演算法
靜態方法：僅根據演算法本身實現調度；實現起點公平，不管伺服器當前處理多少請求，分配的數量一致
動態方法：根據演算法及後端RS當前的負載狀況實現調度；不管以前分了多少，只看分配的結果是不是公平
靜態調度演算法(static Sche)（4種）:
(1)rr (Round Robin) :輪叫,輪詢
說明：輪詢調度演算法的原理是每一次把來自用戶的請求輪流分配給內部中的伺服器，從1開始，直到N(內部伺服器個數)，然後重新開始循環。演算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。缺點：是不考慮每台伺服器的處理能力。
(2)wrr (Weight Round Robin) :加權輪詢(以權重之間的比例實現在各主機之間進行調度)
說明：由於每台伺服器的配置、安裝的業務應用等不同，其處理能力會不一樣。所以，我們根據伺服器的不同處理能力，給每個伺服器分配不同的權值，使其能夠接受相應權值數的服務請求。
(3)sh (Source Hashing) : 源地址hash實現會話綁定sessionaffinity
說明：簡單的說就是有將同一客戶端的請求發給同一個real server,源地址散列調度演算法正好與目標地址散列調度演算法相反，它根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的並且沒有超負荷，將請求發送到該伺服器，否則返回空。它採用的散列函數與目標地址散列調度演算法的相同。它的演算法流程與目標地址散列調度演算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址。
(4)dh : (Destination Hashing) : 目標地址hash
說明：將同樣的請求發送給同一個server,一般用於緩存伺服器，簡單的說，LB集群後面又加了一層，在LB與realserver之間加了一層緩存伺服器，當一個客戶端請求一個頁面時,LB發給cache1,當第二個客戶端請求同樣的頁面時，LB還是發給cache1,這就是我們所說的，將同樣的請求發給同一個server,來提高緩存的命中率。目標地址散列調度演算法也是針對目標IP地址的負載均衡，它是一種靜態映射演算法，通過一個散列（Hash）函數將一個目標IP地址映射到一台伺服器。目標地址散列調度演算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。
動態調度演算法(dynamic Sche)（6種）:
(1)lc (Least-Connection Scheling): 最少連接
說明：最少連接調度演算法是把新的連接請求分配到當前連接數最小的伺服器，最小連接調度是一種動態調度短演算法，它通過伺服器當前所活躍的連接數來估計伺服器的負載均衡，調度器需要記錄各個伺服器已建立連接的數目，當一個請求被調度到某台伺服器，其連接數加1，當連接中止或超時，其連接數減一，在系統實現時，我們也引入當伺服器的權值為0時，表示該伺服器不可用而不被調度。此演算法忽略了伺服器的性能問題，有的伺服器性能好，有的伺服器性能差，通過加權重來區分性能，所以有了下面演算法wlc。
簡單演算法：active*256+inactive (誰的小，挑誰)
(2)wlc (Weighted Least-Connection Scheling):加權最少連接
加權最小連接調度演算法是最小連接調度的超集，各個伺服器用相應的權值表示其處理性能。伺服器的預設權值為1，系統管理員可以動態地設置伺服器的許可權，加權最小連接調度在調度新連接時盡可能使伺服器的已建立連接數和其權值成比例。由於伺服器的性能不同，我們給性能相對好的伺服器，加大權重，即會接收到更多的請求。
簡單演算法：（active*256+inactive）/weight（誰的小，挑誰）
(3)sed (shortest expected delay scheling):最少期望延遲
說明：不考慮非活動連接，誰的權重大，我們優先選擇權重大的伺服器來接收請求，但會出現問題，就是權重比較大的伺服器會很忙，但權重相對較小的伺服器很閑，甚至會接收不到請求，所以便有了下面的演算法nq。
基於wlc演算法，簡單演算法：（active+1)*256/weight （誰的小選誰）
(4).nq (Never Queue Scheling): 永不排隊
說明：在上面我們說明了，由於某台伺服器的權重較小，比較空閑，甚至接收不到請求，而權重大的伺服器會很忙，所此演算法是sed改進，就是說不管你的權重多大都會被分配到請求。簡單說，無需隊列，如果有台real server的連接數為0就直接分配過去，不需要在進行sed運算。
(5).LBLC(Locality-Based Least Connections) :基於局部性的最少連接
說明：基於局部性的最少連接演算法是針對請求報文的目標IP地址的負載均衡調度，主要用於Cache集群系統，因為Cache集群中客戶請求報文的目標IP地址是變化的，這里假設任何後端伺服器都可以處理任何請求，演算法的設計目標在伺服器的負載基本平衡的情況下，將相同的目標IP地址的請求調度到同一個台伺服器，來提高伺服器的訪問局部性和主存Cache命中率，從而調整整個集群系統的處理能力。
(6).LBLCR(Locality-Based Least Connections with Replication) :基於局部性的帶復制功能的最少連接
說明：基於局部性的帶復制功能的最少連接調度演算法也是針對目標IP地址的負載均衡，該演算法根據請求的目標IP地址找出該目標IP地 址對應的伺服器組，按「最小連接」原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載，則按「最小連接」原則從這個集群中選出一台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除， 以降低復制的程度。

⑥ 新的連接被依次分布到各個時伺服器的調度演算法是

摘要 您好，1、輪詢調度

⑦ slb配置詳解

我們一起來快速認識一下，負載均衡——SLB。負載均衡SLB是將訪問流量根據轉發策略分發到後端多台雲伺服器（ECS實例）的流量分發控制服務。包含兩種含義：一是通過流量分發，擴展應用系統的服務能力；二是消除單點故障，提高應用系統的可用性。

應用場景
我們具體來看一看它的使用場景。
第一個使用場景的是用於高訪問量的業務。
當你的應用訪問量非常大，單台的伺服器已經無法承載這個訪問量的時候，就可以使用負載均衡，將流量分發到不同的伺服器上去。
第二個場景是橫向擴張系統。
當你已經使用了負載均衡，在業務有波動時可以在後端非常方便的添加和減少ECS來調整自己應用的服務能力。
第三個應用場景是消除單點故障。
當我們在使用負載均衡時，後端有多台ECS在同時工作的。一旦其中一台ECS上的應用發生了故障，那麼負載均衡會通過一個健康檢查的機制來及時的發現這個故障，並且能屏蔽對這台ECS的流量轉發，然後將用戶的請求轉發到另一台正常工作的ECS實例上。
同城的容災
阿里雲負載均衡可以實現同地域多可用區之間同地域容災，當主可用區出現故障是，可以在短時間內切換到另一備用可用區，以恢復服務能力。同時，主可用區恢復訪問時，它會自動切換到主可用區。


跨地域容災
跨地域容災通過雲解析做智能DNS，將域名解析到不同地域的負載均衡實例地址下，以實現全局負載均衡，當某個地域出現不可用時，暫停對應解析即可實現所有用戶訪問不受影響。

配置負載均衡
下面我們來演示一下負載均衡該如何去配置。
首先要做好准備工作，我們需要開通一台負載均衡實例和與負載均衡同一個地域的兩台ECS伺服器。

創建好以後，我們就可以在負載均衡的控制台看到這樣一台實例了。
接下來，我們要給這個負載均衡創建一個監聽。「監聽」可以簡單的理解為對應後端伺服器裡面的一個應用，比如一個網站我們來點擊監聽，然後點擊添加監聽。


假設我們的後端伺服器裡面有一個http的網站前端協議埠，我們可以將前後端協議埠TCP都寫成80，然後根據自己的需要來選擇調度演算法，其實就是流量的轉發方式。

下一步是健康檢查，我們可以選擇TCP方式。

健康檢查埠會默認的和後端伺服器的埠保持一致，直接確認就好了。現在，一個監聽就配置好了。
接下來要去規定這台負載均衡的後端伺服器是哪些。點擊後端伺服器，然後點擊未添加伺服器，將我們剛才創建的兩台伺服器勾選，然後批量添加就可以了。

這里有一個權重需要大家注意一下，這里的權重就是一個比例的概念，如果兩台伺服器寫的都是100，流量將會以1:1的方式被轉發到後端的兩台伺服器上。

⑧ 如何配置Web伺服器實現負載均衡

網路的負載均衡是一種動態均衡技術，通過一些工具實時地分析數據包，掌握網路中的數據流量狀況，把任務合理均衡地分配出去。這種技術基於現有網路結構，提供了一種擴展伺服器帶寬和增加伺服器吞吐量的廉價有效的方法，加強了網路數據處理能力，提高了網路的靈活性和可用性。

以四台伺服器為例實現負載均衡：

安裝配置LVS

1. 安裝前准備：

(1)首先說明，LVS並不要求集群中的伺服器規格劃一，相反，可以根據伺服器的不同配置和負載狀況，調整負載分配策略，充分利用集群環境中的每一台伺服器。如下表：

Srv Eth0 Eth0：0 Eth1 Eth1：0

vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254

vsbak 10.0.0.3 192.168.10.102

real1 192.168.10.100

real2 192.168.10.101

其中，10.0.0.2是允許用戶訪問的IP。

(2)這4台伺服器中，vs1作為虛擬伺服器(即負載平衡伺服器)，負責將用戶的訪問請求轉發到集群內部的real1，real2，然後由real1，real2分別處理。
Client為客戶端測試機器，可以為任意操作系統。

(3)所有OS為redhat6.2，其中vs1 和vsbak 的核心是2.2.19， 而且patch過ipvs的包， 所有real
server的Subnet mask 都是24位， vs1和vsbak 的10.0.0. 網段是24 位。

2.理解LVS中的相關術語

(1) ipvsadm ：ipvsadm是LVS的一個用戶界面。在負載均衡器上編譯、安裝ipvsadm。

(2) 調度演算法： LVS的負載均衡器有以下幾種調度規則：Round-robin，簡稱rr;weighted
Round-robin，簡稱wrr;每個新的連接被輪流指派到每個物理伺服器。Least-connected，簡稱lc;weighted
Least-connected，簡稱wlc，每個新的連接被分配到負擔最小的伺服器。

(3) Persistent client
connection，簡稱pcc，(持續的客戶端連接，內核2.2.10版以後才支持)。所有來自同一個IP的客戶端將一直連接到同一個物理伺服器。超時時間被設置為360秒。Pcc是為https和cookie服務設置的。在這處調度規則下，第一次連接後，所有以後來自相同客戶端的連接(包括來自其它埠)將會發送到相同的物理伺服器。但這也會帶來一個問題，因為大約有25%的Internet
可能具有相同的IP地址。

(4) Persistent port
connection調度演算法：在內核2.2.12版以後，pcc功能已從一個調度演算法(你可以選擇不同的調度演算法：rr、wrr、lc、wlc、pcc)演變成為了一個開關選項(你可以讓rr、
wrr、lc、wlc具備pcc的屬性)。在設置時，如果你沒有選擇調度演算法時，ipvsadm將默認為wlc演算法。 在Persistent port
connection(ppc)演算法下，連接的指派是基於埠的，例如，來自相同終端的80埠與443埠的請求，將被分配到不同的物理伺服器上。不幸的是，如果你需要在的網站上採用cookies時將出問題，因為http是使用80埠，然而cookies需要使用443埠，這種方法下，很可能會出現cookies不正常的情況。

(5)Load Node Feature of Linux Director：讓Load balancer 也可以處理users 請求。

(6)IPVS connection synchronization。

(7)ARP Problem of LVS/TUN and LVS/DR：這個問題只在LVS/DR，LVS/TUN 時存在。

3. 配置實例

(1) 需要的軟體包和包的安裝：

I. piranha-gui-0.4.12-2*.rpm (GUI介面cluster設定工具);

II. piranha-0.4.12-2*.rpm;

III. ipchains-1.3.9-6lp*.rpm (架設NAT)。

取得套件或mount到光碟，進入RPMS目錄進行安裝:

# rpm -Uvh piranha*

# rpm -Uvh ipchains*

(2) real server群：

真正提供服務的server(如web
server)，在NAT形式下是以內部虛擬網域的形式，設定如同一般虛擬網域中Client端使用網域：192.168.10.0/24
架設方式同一般使用虛擬IP之區域網絡。

a. 設網卡IP

real1 ：192.168.10.100/24

real2 ：192.168.10.101/24

b.每台server均將default gateway指向192.168.10.254。
192.168.10.254為該網域唯一對外之信道，設定在virtual server上，使該網域進出均需通過virtual server 。

c.每台server均開啟httpd功能供web server服務，可以在各real server上放置不同內容之網頁，可由瀏覽器觀察其對各real
server讀取網頁的情形。

d.每台server都開啟rstatd、sshd、rwalld、ruser、rsh、rsync，並且從Vserver上面拿到相同的lvs.conf文件。

(3) virtual server：

作用在導引封包的對外主機，專職負責封包的轉送，不提供服務，但因為在NAT型式下必須對進出封包進行改寫，所以負擔亦重。

a.IP設置：

對外eth0：IP：10.0.0.1 eth0：0 ：10.0.0.2

對內eth1：192.168.10.1 eth1：0 ：192.168.10.254

NAT形式下僅virtual server有真實IP，real server群則為透過virtual server.

b.設定NAT功能

# echo 1 >; /proc/sys/net/ipv4/ip_forward

# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag

# ipchains -P forward MASQ

c.設定piranha 進入X-window中 (也可以直接編輯/etc/lvs.cf )

a).執行面板系統piranha

b).設定「整體配置」(Global Settings) 主LVS伺服器主機IP：10.0.0.2， 選定網路地址翻譯(預設) NAT路徑名稱：
192.168.10.254， NAT 路徑裝置： eth1：0

c).設定虛擬伺服器(Virtual Servers) 添加編輯虛擬伺服器部分：(Virtual
Server)名稱：(任意取名);應用：http;協議： tcp;連接：80;地址：10.0..0.2;裝置：eth0：0; 重入時間：180
(預設);服務延時：10 (預設);載入監控工具：ruptime (預設);調度策略：Weighted least-connections; 持續性：0
(預設); 持續性屏蔽： 255.255.255.255 (預設); 按下激活：實時伺服器部分：(Real Servers); 添加編輯：名字：(任意取名);
地址： 192.168.10.100; 權重：1 (預設) 按下激活

另一架real server同上，地址：192.168.10.101。

d). 控制/監控(Controls/Monitoring)
控制：piranha功能的激活與停止，上述內容設定完成後即可按開始鍵激活piranha.監控器：顯示ipvsadm設定之routing table內容
可立即更新或定時更新。

(4)備援主機的設定(HA)

單一virtual server的cluster架構virtual server 負擔較大，提供另一主機擔任備援，可避免virtual
server的故障而使對外服務工作終止;備份主機隨時處於預備狀態與virtual server相互偵測

a.備份主機：

eth0： IP 10.0.0.3

eth1： IP 192.168.10.102 同樣需安裝piranha，ipvsadm，ipchains等套件

b.開啟NAT功能(同上面所述)。

c.在virtual server(10.0.0.2)主機上設定。

a).執行piranha冗餘度 ;

b).按下「激活冗餘度」;

冗餘LVS伺服器IP： 10.0.0.3;HEARTBEAT間隔(秒數)： 2 (預設)

假定在…秒後進入DEAD狀態： 5 (預設);HEARTBEAT連接埠： 539 (預設)

c).按下「套用」;

d).至「控制/監控」頁，按下「在當前執行層添加PULSE DEAMON」 ，按下「開始」;

e).在監控器按下「自動更新」，這樣可由窗口中看到ipvsadm所設定的routing table，並且動態顯示real
server聯機情形，若real server故障，該主機亦會從監視窗口中消失。

d.激活備份主機之pulse daemon (執行# /etc/rc.d/init.d/pulse start)。

至此，HA功能已經激活，備份主機及virtual server由pulse daemon定時相互探詢，一但virtual
server故障，備份主機立刻激活代替;至virtual server 正常上線後隨即將工作交還virtual server。

LVS測試

經過了上面的配置步驟，現在可以測試LVS了，步驟如下：

1. 分別在vs1，real1，real2上運行/etc/lvs/rc.lvs_dr。注意，real1，real2上面的/etc/lvs
目錄是vs2輸出的。如果您的NFS配置沒有成功，也可以把vs1上/etc/lvs/rc.lvs_dr復制到real1，real2上，然後分別運行。確保real1，real2上面的apache已經啟動並且允許telnet。

2. 測試Telnet：從client運行telnet 10.0.0.2，
如果登錄後看到如下輸出就說明集群已經開始工作了：(假設以guest用戶身份登錄)

[guest@real1 guest]$——說明已經登錄到伺服器real1上。

再開啟一個telnet窗口，登錄後會發現系統提示變為：

[guest@real2 guest]$——說明已經登錄到伺服器real2上。

3. 測試http：從client運行iexplore http://10.0.0.2

因為在real1 和real2 上面的測試頁不同，所以登錄幾次之後，顯示出的頁面也會有所不同，這樣說明real server 已經在正常工作了。

⑨ 接觸過的Nginx的負載均衡演算法有哪些

Nginx 官方默認的幾種負載均衡的演算法
①Round-Robin RR輪詢（默認） 一次一個的來（理論上的，實際實驗可能會有間隔）
②weight 權重 權重高多分發一些 伺服器硬體更好的設置權重更高一些
③ip_hash 同一個IP，所有的訪問都分發到同一個web伺服器
第三方模塊實現的調度演算法 需要編譯安裝第三方模塊
④fair 根據後端伺服器的繁忙程度 將請求發到非繁忙的後端伺服器
⑤url_hash 如果客戶端訪問的url是同一個，將轉發到同一台後端伺服器
看你在學習Nginx的知識，推薦你去看黑馬程序員視頻庫，裡面有它的學習視頻，講解的很詳細哦！

⑩ 鏈路負載均衡的鏈路負載均衡包括以下幾個基本元素：

l LB device：負責將內網到外網流量分發到多條物理鏈路的設備。
l 物理鏈路：運營商提供的實際鏈路。
l DIP：用戶發送報文的目的網段。
l 鏈路帶寬：運營商提供給此鏈路的實際帶寬。
l 鏈路閾值：流量超過此鏈路閾值時會進行相應帶寬調度。
l 鏈路權重：多條鏈路在同一調度策略中，根據加權調度演算法將目標流量根據權重比進行分發。
l 健康檢查：檢查運營商鏈路的質量。
l 所屬運營商：確定此條鏈路所屬哪個運營商。
l 路由模式：確定此條鏈路需要下發哪些路由。
l 目的IP組：確定去往此目的運營商IP所走的鏈路。
l 源地址組：確定哪些內網用戶能匹配此條鏈路。
l 協議：確定哪些協議能匹配此條鏈路。
l 入介面：確定從哪些介面流入的流量能匹配此條鏈路。
l 策略動作：當所選物理鏈路都超閾值後，設備對超閾值流量的處理方式。
l 會話保持：匹配源目ip的同一會話在老化時間內走同一條鏈路。
l DNS透明代理：內網用戶向外網域名請求時，設備將此報文攔截重新選擇負載最小的鏈路轉發。
CDN是個很龐大的概念和體系.全世界CDN服務提供商屈指可數.
我們熟悉的Google就是某CDN的最大客戶.我們今天只選取其中一小部分來討論.
說了半天.看上去似乎很復雜.鑒於經典的大多是搞WEB的.接觸的最多的是WEB伺服器/資料庫等.既然是淺談.我就舉個簡單的例子.