負載根據什麼分發到各個伺服器

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

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

Ⅱ 負載均衡是怎麼做的~

1、服務直接返回：這種安裝方式負載均衡的LAN口不使用，WAN口與伺服器在同一個網路中，互聯網的客戶端訪問負載均衡的虛IP（VIP），虛IP對應負載均衡機的WAN口，負載均衡根據策略將流量分發到伺服器上，伺服器直接響應客戶端的請求。

2、橋接模式：橋接模式配置簡單，不改變現有網路。負載均衡的WAN口和LAN口分別連接上行設備和下行伺服器。LAN口不需要配置IP（WAN口與LAN口是橋連接），所有的伺服器與負載均衡均在同一邏輯網路中。

3、路由模式：路由模式的部署方式，伺服器的網關必須設置成負載均衡機的LAN口地址，且與WAN口分署不同的邏輯網路。因此所有返回的流量也都經過負載均衡。這種方式對網路的改動小，能均衡任何下行流量。

(2)負載根據什麼分發到各個伺服器擴展閱讀

負載均衡的演算法:

1、隨機演算法：Random隨機，按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

2、哈希演算法：一致性哈希一致性Hash，相同參數的請求總是發到同一提供者。當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

3、URL散列：通過管理客戶端請求URL信息的散列，將發送至相同URL的請求轉發至同一伺服器的演算法。

參考資料

網路-負載均衡

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

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

Ⅳ 負載均衡概述

1、負載均衡（Load Balance）建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴展網路設備和伺服器的帶寬、增加吞吐量、加強網路數據處理能力、提高網路的靈活性和可用性。負載均衡有兩方面的含義：首先，大量的並發訪問或數據流量分擔到多台節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束後，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。

2、簡單來說就是：其一是將大量的並發處理轉發給後端多個節點處理，減少工作響應時間；其二是將單個繁重的工作轉發給後端多個節點處理，處理完再返回給負載均衡中心，再返回給用戶。目前負載均衡技術大多數是用於提高諸如在Web伺服器、FTP伺服器和其它關鍵任務伺服器上的Internet伺服器程序的可用性和可伸縮性。

1）二層負載均衡（mac）
根據OSI模型分的二層負載，一般是用虛擬mac地址方式，外部對虛擬MAC地址請求，負載均衡接收後分配後端實際的MAC地址響應
2）三層負載均衡（ip）
一般採用虛擬IP地址方式，外部對虛擬的ip地址請求，負載均衡接收後分配後端實際的IP地址響應
3）四層負載均衡（tcp）
在三次負載均衡的基礎上，用ip+port接收請求，再轉發到對應的機器
4）七層負載均衡（http）
根據虛擬的url或IP，主機名接收請求，再轉向相應的處理伺服器

1.四層負載均衡工作在OSI模型中的四層，即傳輸層。四層負載均衡只能根據報文中目標地址和源地址對請求進行轉發，而無法修改或判斷所請求資源的具體類型，然後經過負載均衡內部的調度演算法轉發至要處理請求的伺服器。四層負載均衡單純的提供了終端到終端的可靠連接，並將請求轉發至後端，連接至始至終都是同一個。LVS就是很典型的四層負載均衡。

2.七層負載均衡工作在OSI模型的第七層應用層，所以七層負載均衡可以基於請求的應用層信息進行負載均衡，例如根據請求的資源類型分配到後端伺服器，而不再是根據IP和埠選擇。七層負載均衡的功能更豐富更靈活，也能使整個網路更智能。如上圖所示，在七層負載均衡兩端(面向用戶端和伺服器端)的連接都是獨立的。

3.簡言之，四層負載均衡就是基於IP+埠實現的。七層負載均衡就是通過應用層資源實現的。

1、抗負載能力強。抗負載能力強、性能高，能達到F5硬體的60%；對內存和cpu資源消耗比較低
2、工作在網路4層，通過vrrp協議轉發（僅作分發之用），具體的流量由linux內核處理，因此沒有流量的產生。
2、穩定性、可靠性好，自身有完美的熱備方案；（如：LVS+Keepalived）
3、應用范圍比較廣，工作在四層，所以不用考慮要處理的具體應用，可以對所有應用做負載均衡；
4、不支持正則處理，不能做動靜分離。
5、支持負載均衡演算法：rr（輪循）、wrr（帶權輪循）、lc（最小連接）、wlc（權重最小連接）
6、配置 復雜，對網路依賴比較大，穩定性很高。

1、工作在網路的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；
2、Nginx對網路的依賴比較小，理論上能ping通就就能進行負載功能；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的並發；
5、對後端伺服器的健康檢查，只支持通過埠來檢測，不支持通過url來檢測。
6、Nginx對請求的非同步處理可以幫助節點伺服器減輕負載；
7、Nginx僅能支持http、https和Email協議，這樣就在適用范圍較小。
8、不支持Session的直接保持，但能通過ip_hash來解決。
9、支持負載均衡演算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、Ip-hash（Ip哈希）
10、Nginx還能做Web伺服器即Cache功能。

1、支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3、支持url檢測後端的伺服器出問題的檢測會有很好的幫助。
4、更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6、HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
9、支持負載均衡演算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）
10、不能做Web伺服器即Cache

1、 四層、七層負載均衡的區別
2、 四層和七層負載均衡的特點及常用負載均衡Nginx、Haproxy、LVS對比
3、 linux負載均衡總結性說明 四層負載和七層負載有什麼區別

Ⅳ nginx負載均衡根據什麼調用伺服器

lnmp架構 直接放nginx的web文件夾中，通過cgi解析php返回給nginx，如果是lnmpa架構，就是多了個apache,nginx負責分發請求，然後apache調用php_mod解析php,最後返回給nginx 如果是負載均衡，nginx分發請求，每個請求可能請求不同的伺服器

Ⅵ 什麼是F5負載均衡器，看完你就明白怎麼回事了

一、前言

在互聯網雄起的時代，隨著各個網路請求量的不斷增大，利用負載分化請求量，從而達到優化硬體負荷量的目的，一般負載分為軟體負載和硬體負載，比如軟體中使用nginx等工具實現負載均衡，而F5負載均衡器就是硬體網路性能優化設備。

二、何為負載均衡器

那麼什麼是F5負載均衡器呢，通俗的講就是將客戶端請求量通過F5負載到各個伺服器，增加吞吐量，從而降低伺服器的壓力，他不同於交換機、路由器這些網路基礎設備，而是建立在現有網路結構上用來增加網路帶寬和吞吐量的的硬體設備

三、工作原理

1、客戶發出服務請求到VIP

2、BIGIP接收到請求，將數據包中目的IP地址改為選中的後台伺服器IP地址，然後將數據包發出到後台選定的伺服器

3、後台伺服器收到後，將應答包按照其路由發回到BIGIP

4、BIGIP收到應答包後將其中的源地址改回成VIP的地址，發回客戶端，由此就完成了一個標準的伺服器負載平衡的流程。

四、負載均衡涉及到演算法

輪詢演算法：按照順序將每個請求分發到每個伺服器，相當於ngixn負載的輪訓演算法一個道理，當其中某個伺服器發生第二到第7層的故障，BIGIP就把其從順序循環隊列中拿出，不參與下一次的輪訓。

比率：指的是給每個伺服器分配一個加權值，類似於權重，輪訓會根據和這個權重去訪問具體要到哪台伺服器。

優先權：給所有伺服器分組，BIGIP用戶的請求，分配給優先順序最高的伺服器組（在同一組內，採用輪詢或比率演算法，分配用戶的請求）；當最高優先順序中所有伺服器出現故障，BIGIP才將請求送給次優先順序的伺服器組。

最快模式：傳遞連接給那些響應最快的伺服器。當發生異常故障時，BIGIP就會將其拿出來作為當前相應伺服器，此時就不參與其他用戶的請求輪訓分配。

觀察模式：以連接數和相應時間為准，當放生故障時BIGIP會將其拿出來作為請求的相應伺服器，並且也不參與其他用戶請求，直至恢復正常為止。

預測模式：BIGIP利用收集到的伺服器當前的性能指標，進行預測分析，選擇一台伺服器在下一個時間片內，其性能將達到最佳的伺服器相應用戶的請求。

動態性能分配:BIGIP收集到的應用程序和應用伺服器的各項性能參數，動態調整流量分配。

動態伺服器補充:當主伺服器群中因故障導致數量減少時，動態地將備份伺服器補充至主伺服器群。

服務質量：按不同的優先順序對數據流進行分配。

服務類型：按不同的服務類型（在Type of Field中標識）對數據流進行分配。

規則模式：針對不同的數據流設置導向規則，用戶可自行編輯流量分配規則，BIGIP利用這些規則對通過的數據流實施導向控制。

五。結尾

總之F5負載均衡器涉及到的原理內容多而雜，重點用戶硬體負載方面，目前理解到此，還有很多不足之處希望一起發文討論。

Ⅶ 請教一下：負載均衡伺服器自身是怎樣抗住高並發的

1、負載原理

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

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

2、負載方案

1）、硬負載---通過在應用服務上層添加負載設備（F5），對訪問請求根據後端應用服務的負載情況進行分發到各個伺服器

2）、軟負載----使用三方、開源軟體(proxy、nginx)的配置，部署負載架構

簡單負載架構：

3、高並發負載方案

1、擴容服務集群節點，增加相應節點數

2、擴容負載集群節點，減少單節點分流壓力

Ⅷ 負載均衡問題

大型網站使用的多為分布式技術，採用負載均衡將壓力分攤給各個伺服器。
負載均衡的技術在外部，使用DNS負載均衡。一個域名可以解析為多個IP地址。用戶雖然訪問同一個域名，但是會被均衡分配到不同的IP上。在內部，使用LVS、nginx、haproxy等軟體或F5等硬體進行負載均衡。從同一個IP進入的請求，通過軟體或硬體的負載均衡調度到不同的後台伺服器上進行處理和返回。
大型網站的資料庫集群有多種方案。一種是資料庫集群在內部能進行自動的寫同步，一處修改則所有資料庫同步修改。另外一種是分布式的資料庫。如HBase等。

Ⅸ 負載均衡概述及優缺點對比

隨著用戶訪問的增多，一個應用伺服器不能滿足需求了，就需要部署多台應用伺服器，通過負載均衡，將數據分發到不同的應用伺服器。
從作用來看，和緩存集群的分發很相似，但是有不同。緩存需要發送到特定的伺服器。但是，由於應用伺服器是無狀態的，因此，負載均衡不用根據請求分發到特定伺服器，發送到哪個應用伺服器都可以。
因此，負載均衡關注的技術焦點有兩個，分別是：網路通信、路由選擇

網路通信分為以下幾種方法。

負載均衡伺服器什麼都不做，重定向響應

這種方法優點是簡單，但是缺點也很明顯：

由於這些問題，這種方法，在現實中幾乎沒有人使用。

每次請求DNS解析到IP地址不同，從而訪問到不同到應用伺服器。
這種方法，性能方面沒有問題，雖然，還是2次http請求，但是不是每一次請求都需要域名解析，一次解析，ip就會記錄到本地。下次，直接訪問記錄的ip。因此，性能無問題。
但是，由於域名解析伺服器解析出的ip，如果出錯，不會很快更新，且用戶已經本地存儲了ip也不會很快改變。因此，採用這種方案時，需要兩級負載均衡。若應用伺服器出錯，在第二層負載均衡去掉。
對於安全性，現實使用時，該方法主要適用於兩層負載均衡的情況，DNS負載均衡用於第一層負載均衡，解析出來的是第二層負載均衡伺服器，因此，脆弱的伺服器還是可以在內網中。淘寶、網路，不同時間ping，返回地址不同，意味著都是用了DNS負載均衡。

在應用層進行負載均衡，收到請求時，將請求轉發到內網，再將收到的內網響應，返回給用戶。
nagix本身的反向代理伺服器，就有該功能。一般應用伺服器是幾十台，這種模式夠用，再多一些，會不夠用。因此，大一些的網站不會使用。
因為用的http請求協議，http比較重（比tcp的包重）。對反向代理伺服器壓力很大，其通過應用程序級別的線/進程才能完成分發，還要等應用伺服器返回，因此，會有性能瓶頸。即使負載均衡做集群效率也低，因為後面的應用伺服器有限。
因此，可以應用的規模很有限。

負載均衡伺服器，和反向代理負載均衡原理相同，但是是在tcp層，修改包中源地址和目標地址，並發送到內網，收到響應後，再修改目標地址和原地址，返回給用戶。
因為，負載均衡伺服器處理的是ip那一層包，因此，處理能力可以提高。
但是，這種方法，請求和響應都通過了負載均衡，尤其是響應一般比較大。響應出口網路帶寬會成為瓶頸。

數據鏈路層負載均衡，IP地址不變，只修改網卡MAC地址。應用伺服器和負載均衡伺服器共享一個虛擬ip。因為ip沒有被修改過，tcp/ip協議還是通的，可以通過校驗。又由於目的地址的mac地址改變了，因此，處理響應不用再經過負載均衡伺服器。
大型互聯網應用主要使用的負載均衡方案，也稱為負載均衡的三角模式。

輪詢
....

該方案已經被淘汰的。
通過session復制的方式，集群規模會受限制，復制不過來。做集群就是因為用戶請求多，請求多，session也多，如果每個都有所有的session，對伺服器壓力很大。

來自相同的ip，總是到同一個應用伺服器。這種方法也很快就淘汰了。
因為，會話需要會話關閉，如果因為發布程序，kill進程，session丟失。系統的可用性會下降。

發請求時，帶cookie發送伺服器，session記錄的cookie中，返回給瀏覽器。任何一台伺服器可以重cookie里得到session。
缺點：cookie變大，網路開銷有影響。且有些瀏覽器禁用cookie，不好用。
早期使用的這個方案。缺點明顯，但是生命力強。
對伺服器架構要求很低。

Ⅹ 負載均衡 是如何如何分發 請求到用戶最近的伺服器的

如果你是看CDN的東西看到的這句話，那麼我可以來解釋一下流程。「全局負載均衡技術將用戶的訪問指向離用戶最近的工作正常的流媒體伺服器上」。首先我們要明確幾件事:
1、在CDN的案例圖中，其實B和C不會在不同的城域。如果在不同的城市，一般會在那個地域也放置一個反向代理伺服器或反向代理節點。B和C為同一地域，A為B、C的負載均稀器或調度器；
2、CDN的部署里，為避免單點故障或應對業務峰值，A並不是單台伺服器，一般由多台伺服器進行調度，一般採用LVS進行七層的負載和轉發。通過LVS的負載均衡策略將業務轉發至B和C，負載均衡策略可以進行設置，如輪詢，權重輪詢、隨機等等；
3、CDN一般由DNS來做為用戶流量調度，也是CDN的核心，即將用戶的請求調度至距用戶最近的節點，例如節點D，節點D通過負載均衡策略將請求分發至節點D後端的業務伺服器E和F。
4、你看到的這句話，是指DNS層面的調度。

流媒體業務使用CDN的發布業務的前提和流程如下：
1、在流媒體業務伺服器域名注冊商修改域名的CNAME記錄為CDN服務廠商的域名；（這一步是使用CDN的首要條件）
2、CDN服務廠商為業務設置不同地域的緩存節點，如北京、上海、美國等
3、不同地域設置的緩存節點具有不同的IP地址地址池，並且該節點內擁有業務調度器（LVS的DR）及真正的業務緩存伺服器，緩存伺服器通過類似Squid等程序定期緩存流媒體業務伺服器的視頻信息及網頁信息，每隔一段時間進行更新請求；
4、用戶通過DNS調度請求到某一節點時，該節點通過LVS技術將用戶的請求調度至節點內某一以緩存節點進行處理，並返回結果給用戶；（可參照LVS的工作模式）
5、當緩存節點有用戶請求的內容時，將直接返回內容給用戶，當緩存節點發現請求的內容不存在時，會主動返迴流媒體業務的源伺服器進行內容請求，並將結果緩存至緩存節點。
6、
用戶最終拿到緩存節點上的視頻內容及信息，由於通過DNS調度至用戶最近的節點，通過LVS調度至最快最優的伺服器進行處理，故加快了用戶訪問網站及視頻
的速度。（視頻的加速其實還有一種技術叫cache技術，即將視頻提前下載到距用戶最近的節點，用戶看起來等於在區域網中查看）

DNS和CDN調度的流程如下：
1、用戶訪問流媒體業務的域名如「www.abc.com";
2、www.abc.com的cname記錄為CDN服務廠商的域名，如www.abc.com.cdncache01.com；
3、用戶的請求被轉發至www.abc.com.cdncache01.com進行處理，即觸發用戶對www.abc.com.cdncache01.com域名的解析處理。DNS解析流程見圖「DNS解析流程圖」
4、
www.abc.com.cdncache01.com域名在權威伺服器里配置的記錄為多條的，即智能DNS，可參考DNSPOD，即一個域名可以根據地
域的不同配置不同的解析策略，源地址為北京聯通的，即解析為用戶指定的聯通伺服器IP地址，源地址為廣州移動的，即解析的IP地址為用戶指定廣州移動的
IP地址。
5、DNS通過AnyCast技術進行三層負載均衡，類似於OSPF的等價路由，如8.8.8.8這個地址實際為一個AnyCast地
址，即谷歌全球的遞歸DNS伺服器均使用8.8.8.8作為Global
DNS地址，當用戶通過8.8.8.8請求域名解析時會帶上自己的DNS伺服器地址進行請求，即8.8.8.8會查詢請求過來的客戶端地址是哪裡的IP地
址，如果是北京聯通的，即將請求解析為北京聯通的一個IP地址或解析為北京聯通的一個負載均衡節點CNAME域名。
6、為了達到更精準備的DNS
解析調度，谷歌還研發了edns-client-subnet，即在DNS授權、遞歸、緩存上均支持該Edns協議，支持該協議後，用戶在請求DNS域名
解析時，會帶上自己客戶端的源IP地址放在請求包里，而非客戶端配置的DNS伺服器IP地址。這樣就有效的避免了用戶使用Global
DNS伺服器時不能調度精準的問題。（有關DNS授權、遞歸等問題可以參照RFC 1034和1035）
7、按照以上流程用戶請求www.abc.com.cdncache01.com，會得到一個距離用戶上網所在地域最近的一個CDN緩存節點的IP地址即樓主圖中的反向代理服務節點。假設IP地址為1.2.3.4。
8、用戶請求1.2.3.4的流媒體業務，節點1.2.3.4通過LVS及其它負載均衡技術將用戶的請求分發布該節點內最優最快的緩存伺服器，如伺服器E，IP地地址為192.168.1.4，即由192.168.1.4進行業務處理。
9，伺服器192.168.1.4直接將結果返回給用戶。