您好,登錄后才能下訂單哦!
今天小編給大家分享一下服務器與客戶端負載均衡的方法的相關知識點,內容詳細,邏輯清晰,相信大部分人都還太了解這方面的知識,所以分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后有所收獲,下面我們一起來了解一下吧。
是指單臺服務器性能達到極限時通過服務器集群來橫向增加系統的吞吐量和性能。一說負載均衡我們想到的就是Ngnix,不和否認,Ngnix是負載均衡分廠棒的實現方式,之一!但是面試的時候面試官往往希望能夠通過一個螺絲釘能夠牽連出整個車間,如果單單回復Ngnix,想通過面試可能還欠些火候。
服務器負載均衡就是我們平時說的負載均衡,是指在服務器上游做服務分發,常用的方式有一下幾種:
1、DNS域名解析負載均衡;假設我們的域名指向了多個IP地址,當一個域名請求來時,DNS服務器機進行域名解析將域名轉換為IP地址是,在1:N的映射轉換中實現負載均衡。DNS服務器提供簡單的負載均衡算法,但當其中某臺服務器出現故障時,通知DNS服務器移除當前故障IP。 2、反向代理負載均衡;反向代理只值對服務器的代理,代理服務器接受請求,通過負載均衡算法,將請求轉發給后端服務器,后端服務返回給代理服務器然后代理服務器返回到客戶端。反向代理服務器的優點是隔離后端服務器和客戶端,使用雙網卡屏蔽真實服務器網絡,安全性更好,相比較于DNS域名解決負載均衡,反向代理在故障處理方面更靈活,支持負載均衡算法的橫向擴展。目前使用非常廣泛。當然反向代理也需要考慮很多問題,比如單點故障,集群部署等。 3、IP負載均衡;我們都知道反向代理工作到HTTP層,本身開銷相對大一些,對性能有一定影響,LVS-NAT是一種衛浴傳輸層的負載均衡,它通過修改接受的數據包目標地址的方式實現負載均衡。Linux2.6.x以后版本內置了IPVS,專注用于實現IP負載均衡,故而在Linux上IP負載均衡使用非常廣泛。LVS-DR工作在數據鏈路層,比LVS-NAT更霸道的時候它直接修改數據包的MAC地址。LVS-TUN——基于IP隧道的請求轉發機制,將調度器收到的IP數據包進行封裝,轉交給服務器,然后服務器返回數據,通過調度器實現負載均衡。這種方式支持跨網段調度。總結一下,LVS-DR和LVS-TUN都適合響應和請求不對稱的Web服務器,如何從它們中做出選擇,取決于你的網絡部署需要,因為LVS-TUN可具有跨地域性,有類似這種需求的,就應該選擇LVS-TUN。
相比較服務器負載均衡而言,客戶端負載均衡是一個非常小眾的概念,但是面試在問道負載均衡相關知識的時候卻會刻意了解候選人的知識廣度。客戶端負載均衡是在spring-cloud分布式框架組件Ribbon中定義的。我們在使用spring-cloud分布式框架時,同一個service大概率同時啟動多個,當一個請求奔過來時,那么這多個service,Ribbon通過策略決定本次請求使用哪個service的方式就是客戶端負載均衡。在spring-cloud分布式框架中客戶端負載均衡對開發者是透明的,添加@LoadBalanced注解就可以了。客戶端負載均衡和服務器負載均衡的核心差異在服務列表本身,客戶端負載均衡服務列表在通過客戶端維護,服務器負載均衡服務列表由中間服務單獨維護。 通過對以上知識的理解,大家能夠對負載均衡有的較為全面的認識,下來我再簡單的和面試官聊一聊常見的負載均衡算法:
隨機,通過隨機選擇服務進行執行,一般這種方式使用較少; 輪訓,負載均衡默認實現方式,請求來之后排隊處理; 加權輪訓,通過對服務器性能的分型,給高配置,低負載的服務器分配更高的權重,均衡各個服務器的壓力; 地址Hash,通過客戶端請求的地址的HASH值取模映射進行服務器調度。 最小鏈接數;即使請求均衡了,壓力不一定會均衡,最小連接數法就是根據服務器的情況,比如請求積壓數等參數,將請求分配到當前壓力最小的服務器上。 其他若干方式。
以上就是“服務器與客戶端負載均衡的方法”這篇文章的所有內容,感謝各位的閱讀!相信大家閱讀完這篇文章都有很大的收獲,小編每天都會為大家更新不同的知識,如果還想學習更多的知識,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。