負載均衡的調度演算法都有哪些

㈠ 伺服器集群的負載均衡演算法有哪些

輪轉(Round-Robin)演算法
加權輪轉(Weighted Round Robin)演算法
最小連接數（Least Connections）演算法
加權最小連接數（Weighted Least Connections）演算法
目的地址哈希散列（Destination Hashing Scheling）演算法
源地址哈希散列（Source Hashing Scheling）演算法
隨機（Random）演算法

㈡ 伺服器做負載均衡有什麼優勢怎麼計算的

西部數碼負載均衡EasySLB服務，即在多台雲主機間實現應用程序流量的自動分配。可實現故障自動切換，提高業務可用性，並提高資源利用率。
西部數碼負載均衡只需要在控制台一鍵即可添加後端伺服器，系統將自動設置好相關路由與網關，讓負載均衡集群的搭建變得輕而易舉

㈢ 軟體架構中，負載均衡有哪些調度演算法

謝邀！
負載均衡調度演算法也叫負載均衡方法有很多種，下面以使用比較廣的nginx為例說說軟體負載均衡的調度演算法：
nginx默認的調度演算法，按照時間順序逐一分配後台伺服器
在server後加weigth，weight值越高，後台伺服器分配概率越大，下圖是說ip為102的後台服務分配概率是ip為101後台服務的兩倍
按照訪問ip的hash分配，增加ip_hash關鍵字，同一ip訪問相同的後台服務
按照訪問url的hash分配，增加url_hash關鍵字，同一url訪問相同的後台服務
按照最少連接數方式分配，增加least_conn關鍵字，哪個後台服務連接數少就分配哪個
按照最短響應時間分配，增加fair關鍵字，響應時間短的後台服務優先分配

㈣ 常見的負載均衡技術

四層負責均衡：主要是指通過判斷報文的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實現了會話粘性

㈤ 簡述負載均衡集群中常見的調度演算法及原理（5種以上）

1.LVS負載均衡集群介紹

2. LVS介紹

3. IPVS發展史

4.LVS體系結構與工作原理簡單描述

5.LVS的基本工作過程

6.LVS的三種工作模式：

6.1NAT模式-網路地址轉換

6.2TUN模式

6.3DR模式（直接路由模式）

㈥ lvs負載均衡（簡介，三種工作模式，四種常用演算法）

一，lvs簡介

LVS是Linux Virtual Server的簡稱，也就是Linux虛擬伺服器，是一個由章文嵩博士發起的自由軟體項目，官方站點是： http://www.linuxvirtualserver.org 。現在LVS已經是Linux標准內核的一部分，在Linux2.4內核以前，使用LVS時必須重新編譯內核以支持LVS功能模塊，但是從Linux2.4內核心之後，已經完全內置了LVS的各個功能模塊，無需給內核打任何補丁，可以直接使用LVS提供的各種功能。使用LVS技術要達到的目標是：通過LVS提供的負載均衡技術和Linux操作系統實現一個高性能，高可用的伺服器群集，它具有良好的可靠性、可擴展性和可操作性。從而以兄棚野低廉的成本實現最優的服務性能。

二，三種工作模式

1、基於NAT的LVS模式負載均衡

也就是網路地址翻譯技術實現虛擬伺服器，當用戶請求到達調度器時，調度器將請求報文的目標地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的目標埠也改成選定的Real Server的相應埠，***將報文請求發送到選定的Real Server。在伺服器端得到數據後，Real Server返回數據給用戶時，需要再次經過負載調度器將報文的源地址和源埠改成虛擬IP地址和相應埠，然後把數據發送給用戶，完成整個負載調度過程。可以看出，在NAT方式下，用戶請求和響應報文都必須經過Director Server地址重寫，當用戶請求越來越多時，調度器的處理能力將稱為瓶頸。

2，基於TUN的LVS負載均衡

也就是IP隧道技術實現虛擬伺服器。它的連接調度和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，調度器採用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server將直接響應用戶的請求，不再經過前端調度器，此外，對Real Server的地域位置沒有要求，可以和Director Server位於同一個網段，也可以是獨立的一個網路。因此，在TUN方式中，調度器將只處理用戶的報文請求，集群系統的吞吐量大大提高。

用的很少，圖省略

3，基於DR的LVS負載均衡

也就是用直接路由技術實現虛擬伺服器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。

三，LVS負載均衡調度演算法

上面我們談到，負載調度器是根據各 個伺服器的負載情況，動和或態地選擇一台Real Server響應用戶請求，那麼動態選擇是如何實現呢，其實也就是我們這里要說的負載調度演算法，根據不同的網路服務需求和伺服器配置，IPVS實現了如下 八種負載調度演算法，這里我們詳細講述最常用的四種調度演算法，剩餘的四種調度演算法請參考其它資料。

3.1  輪叫調度（Round Robin）

「輪叫」調度也叫1:1調度，調度器通過羨喊「輪叫」調度演算法將外部用戶請求按順序1:1的分配到集群中的每個Real Server上，這種演算法平等地對待每一台Real Server，而不管伺服器上實際的負載狀況和連接狀態。

3.2  加權輪叫調度（Weighted Round Robin）

「加 權輪叫」調度演算法是根據Real Server的不同處理能力來調度訪問請求。可以對每台Real Server設置不同的調度權值，對於性能相對較好的Real Server可以設置較高的權值，而對於處理能力較弱的Real Server，可以設置較低的權值，這樣保證了處理能力強的伺服器處理更多的訪問流量。充分合理的利用了伺服器資源。同時，調度器還可以自動查詢Real Server的負載情況，並動態地調整其權值。

3.3  最少鏈接調度（Least Connections）

「最少連接」調度演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器上。如果集群系統的真實伺服器具有相近的系統性能，採用「最小連接」調度演算法可以較好地均衡負載。

3.4  加權最少鏈接調度（Weighted Least Connections）

「加權最少鏈接調度」是「最少連接調度」的超集，每個服務節點可以用相應的權值表示其處理能力，而系統管理員可以動態的設置相應的權值，預設權值為1，加權最小連接調度在分配新連接請求時盡可能使服務節點的已建立連接數和其權值成正比。

其它四種調度演算法分別為：基於局部性的最少鏈接（Locality-Based Least Connections）、帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication）、目標地址散列（Destination Hashing）和源地址散列（Source Hashing），對於這四種調度演算法的含義，本文不再講述，如果想深入了解這其餘四種調度策略的話，可以登陸LVS中文站點 zh.linuxvirtualserver.org，查閱更詳細的信息。

㈦ 多台伺服器負載均衡，怎麼選擇

一般用的就用簡單的輪詢就好了
調度演算法
靜態方法：僅根據演算法本身實現調度；實現起點公平，不管伺服器當前處理多少請求，分配的數量一致
動態方法：根據演算法及後端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地 址對應的伺服器組，按「最小連接」原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載，則按「最小連接」原則從這個集群中選出一台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除， 以降低復制的程度。

㈧ 實現負載均衡的幾種方式

負載均衡的基本概念 負載均衡是指,將請求分發到 多台 應用伺服器,以此來分散 壓力的一種架構方式,他是以集群的方式存在,並且當 某個節點掛掉的時候,可以自動 不再將請求分配到此節點。
2.
實現方式 1. 重定向 這種方式,是通過將請求全部發送到前置機,由前置機通過演算法 得出要分配給那台 應用伺服器,...
3.
負載均衡演算法 1. 輪詢法 將請求按順序輪流地分配到後端伺服器上,它均衡地對待後

㈨ 四層負載均衡技術

通常使用的nginx負載均衡技術， 在網路分層中處於應用層（第七層），nginx與客戶端建立連接（握手），然後再根據請求信息以及本地配置信息，將請求靈活的分發到不同的服務上。nginx這類7層負載均衡的優缺點都很明顯。

除了nginx這種7層負載均衡策略，還有基於傳輸層（4層）的負載均衡策略。通過分析請求的 IP地址以及埠號 進行請求的負載均衡。根據請求處理模式的不同，4層負載均衡 演算法 可以分為： NAT , DR 以及 TUN隧道技術 等。4層負載均衡的實現方式有： LVS 。

NAT(Network Address Translation，網路地址轉換)技術，在專用內部網路中，分配一台實現了NAT技術的路由或服務Load Balance Service。這台負載均衡伺服器分配了公網IP(VIP, Virtual IP)，所有客戶端請求服務都請求此IP。LB通過不同的演算法，將請求數據包的源IP以及目標IP修改，轉發到真實伺服器（Real Service）上進行業務處理。其具體的步驟可以分為：

可以看到通過NAT模式進行負載均衡，所有的請求以及響應都要通過LB伺服器，當訪問量較大時，LB伺服器會成為瓶頸 。

DR(Direct Routing, 直接路由模式)，LB通過修改請求數據包的目標MAC地址，並且在Real Service服務配置只有 自己可見的lo:VIP ，實現數據包的接收（自己沒有VIP的話，服務並不會接收數據包）。整個轉發的流程為：

TUN思想跟DR類似，在Real Service上配置一個內部可見的lo:VIP地址，LB通過封裝或修改數據包信息實現請求的轉發。不同於DR模式LB修改MAC地址，為了 實現不同網段 的Real Service負載，TUN模式通過在原有的數據包外 封裝一層IP Tunnel ，實現數據的轉發。由於封裝完 IP Tunnel 後數據包和正常的數據包結構不同，所以Real Service的 OS需要支持Tunnel功能 。TUN轉發的具體流程為：

LB雖然沒有完全解析數據包無法得知請求信息，但是可以通過監聽請求頭信息（例如，SYN、FIN等）判斷客戶端與Real Service之間的連接情況。LB通過監聽請求信息，維護了各個Real Service的連接信息表。通過這些信息實現不同的調度演算法進行負載均衡。

LB將請求依次轉發至不同的Real Service

給Real Service分配不同的權值，LB根據RS的權值的高低轉發請求

根據請求的目標地址（資源，例如同一URL）進行Hash，轉發至RS上

對客戶端的域名或者IP進行Hash，轉發至RS上

LB將請求轉發至連接最少的RS上

LB通過加權輪詢以及RS的連接情況來轉發請求

LB維護 目標IP到一台RS 的映射表（目標IP最近使用的RS），通過映射表將請求轉發至RS，若RS不存在或者超載，通過 最少連接 策略選出一台新的RS進行轉發

LB維護 目標IP到一組RS 的映射表（目標IP最近使用的RS），通過 最少連接 策略從伺服器組選擇一個RS進行轉發，若RS不存在或者超載，通過 最少連接 策略選出一台新的RS進行轉發，並將此RS加入映射組中。