????????在理解學習負載均衡時,需要了解下網絡協(xié)議的模型,需要知道每一層都支持哪些協(xié)議,又是如何進行負載均衡,是使用軟件,還是使用硬件,熟悉了解后才能更好的掌握負載均衡的實質.
請移步至OSI七層網絡模型進行詳細了解.
小知識:
多層負載解釋說明:????????????
二層負載均衡會通過一個虛擬MAC地址接收請求靖避，然后再分配到真實的MAC地址；????????????
三層負載均衡會通過一個虛擬IP地址接收請求杨拐，然后再分配到真實的IP地址帽揪；????????????
四層負載均衡會通過虛擬IP+端口接收請求搔确，然后再分配到真實的服務器响蕴；????????????
七層負載均衡會通過虛擬的URL或主機名接收請求轰驳，然后再分配到真實的服務器絮识。
一、什么是負載均衡
負載均衡（Load Balance）
????????其意思就是分攤到多個操作單元上進行執(zhí)行室埋，例如Web服務器办绝、FTP服務器、企業(yè)關鍵應用服務器和其它關鍵任務服務器等姚淆，從而共同完成工作任務孕蝉。單從字面上的意思來理解就可以解釋N臺服務器平均分擔負載，不會因為某臺服務器負載高宕機而某臺服務器閑置的情況腌逢。那么負載均衡的前提就是要有多臺服務器才能實現(xiàn)降淮，也就是兩臺以上即可。
二搏讶、負載均衡的優(yōu)點
????????減少服務器的壓力骤肛，將原本一臺服務器索要承受的訪問量分給多臺纳本，并提高項目的可用性，當一臺服務器掛掉的時候不會導致項目癱瘓腋颠。
三、四層負載均衡和七層負載均衡
? ? ? ?七層負載均衡吓笙，主要還是著重于應用廣泛的HTTP協(xié)議淑玫，所以其應用范圍主要是眾多的網站或者內部信息平臺等基于B/S開發(fā)的系統(tǒng)。 四層負載均衡則對應其他TCP應用面睛，例如基于C/S開發(fā)的ERP等系統(tǒng)絮蒿。
????????四層負載均衡工作在OSI模型的傳輸層，主要工作是轉發(fā)叁鉴，它在接收到客戶端的流量以后,通過修改數據包的地址信息將流量轉發(fā)到應用服務器土涝。
可以這樣理解通過發(fā)布三層的IP地址（VIP），然后加四層的端口號幌墓，來決定哪些流量需要做負載均衡但壮，對需要處理的流量進行NAT處理，轉發(fā)至后臺服務器常侣，并記錄下這個TCP或者UDP的流量是由哪臺服務器處理的蜡饵，后續(xù)這個連接的所有流量都同樣轉發(fā)到同一臺服務器處理。
????????七層負載均衡工作在OSI模型的應用層胳施，因為它需要解析應用層流量溯祸，所以七層負載均衡在接到客戶端的流量以后，還需要一個完整的TCP/IP協(xié)議棧舞肆。七層負載均衡會與客戶端建立一條完整的連接,并將應用層的請求流量解析出來焦辅，再按照調度算法選擇一個應用服務器，并與應用服務器建立另外一條連接將請求發(fā)送過去椿胯，因此七層負載均衡的主要工作就是代理筷登。七層負載均衡 也稱為“內容交換”，也就是主要通過報文中的真正有意義的應用層內容压状，再加上負載均衡設備設置的服務器選擇方式仆抵，決定最終選擇的內部服務器。
可以這樣理解為在四層的基礎上（沒有四層是絕對不可能有七層的）种冬，再考慮應用層的特征镣丑，比如同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否需要處理的流量娱两，還可根據七層的URL莺匠、瀏覽器類別、語言來決定是否要進行負載均衡十兢。舉個例子趣竣，如果你的Web服務器分成兩組摇庙，一組是中文語言的，一組是英文語言的遥缕，那么七層負載均衡就可以當用戶來訪問你的域名時卫袒，自動辨別用戶語言，然后選擇對應的語言服務器組進行負載均衡處理单匣。
七層應用需要考慮的問題夕凝。
1.是否真的必要。
????????七層應用的確可以提高流量智能化户秤，同時必不可免的帶來設備配置復雜码秉，負載均衡壓力增高以及故障排查上的復雜性等問題。在設計系統(tǒng)時需要考慮四層七層同時應用的混雜情況鸡号。
2.是否真的可以提高安全性转砖。
????????例如SYN Flood攻擊，七層模式的確將這些流量從服務器屏蔽鲸伴，但負載均衡設備本身要有強大的抗DDoS(一種網絡黑客方式,詳細了解請搜索"DDOS")能力府蔗，否則即使服務器正常而作為中樞調度的負載均衡設備故障也會導致整個應用的崩潰。
3.是否有足夠的靈活度挑围。
????????七層應用的優(yōu)勢是可以讓整個應用的流量智能化礁竞，但是負載均衡設備需要提供完善的七層功能，滿足客戶根據不同情況的基于應用的調度杉辙。最簡單的一個考核就是能否取代后臺Nginx或者Apache等服務器上的調度功能模捂。能夠提供一個七層應用開發(fā)接口的負載均衡設備，可以讓客戶根據需求任意設定功能蜘矢，才真正有可能提供強大的靈活性和智能性狂男。
????????七層負載均衡的優(yōu)點：
? ? ? ? ?1.通過對HTTP報頭的檢查，可以檢測出HTTP400品腹、500和600系列的錯誤信息岖食，因而能透明地將連接請求重新定向到另一臺服務器，避免應用層故障舞吭。
2.可根據流經的數據類型（如判斷數據包是圖像文件泡垃、壓縮文件或多媒體文件格式等），把數據流量引向相應內容的服務器來處理羡鸥，增加系統(tǒng)性能蔑穴。
????3.能根據連接請求的類型，如是普通文本惧浴、圖象等靜態(tài)文檔請求存和，還是asp、cgi等的動態(tài)文檔請求，把相應的請求引向相應的服務器來處理捐腿，提高系統(tǒng)的性能及安全性纵朋。
注*第七層負載均衡受到其所支持的協(xié)議限制（一般只有HTTP），這樣就限制了它應用的廣泛性茄袖，并且檢查HTTP報頭會占用大量的系統(tǒng)資源操软，勢必會影響到系統(tǒng)的性能，在大量連接請求的情況下绞佩，負載均衡設備自身容易成為網絡整體性能的瓶頸寺鸥。
四、負載均衡軟/硬件
軟/硬件負載均衡
軟件負載均衡解決方案是指在一臺或多臺服務器相應的操作系統(tǒng)上安裝一個或多個附加軟件來實現(xiàn)負載均衡品山，負載均衡軟件有Nginx(web服務器軟件)、LVS(Linux Virtual Server linux虛擬服務器軟件)烤低、HaProxy(代理軟件)等是目前使用最廣泛的三種負載均衡軟件肘交。它的優(yōu)點是基于特定環(huán)境，配置簡單扑馁，使用靈活涯呻，成本低廉，可以滿足一般的負載均衡需求腻要。
軟件解決方案缺點也較多复罐，因為每臺服務器上安裝額外的軟件運行會消耗系統(tǒng)不定量的資源，越是功能強大的模塊雄家，消耗得越多效诅，所以當連接請求特別大的時候，軟件本身會成為服務器工作成敗的一個關鍵趟济；軟件可擴展性并不是很好乱投，受到操作系統(tǒng)的限制；由于操作系統(tǒng)本身的Bug顷编，往往會引起安全問題戚炫。
硬件負載均衡解決方案是直接在服務器和外部網絡間安裝負載均衡設備，這種設備我們通常稱之為負載均衡器媳纬，由于專門的設備完成專門的任務双肤，獨立于操作系統(tǒng)，整體性能得到大量提高钮惠，加上多樣化的負載均衡策略茅糜，智能化的流量管理，可達到最佳的負載均衡需求萌腿。?
負載均衡器有多種多樣的形式限匣，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置于服務器與Internet鏈接之間米死，有些則以兩塊網絡適配器將這一功能集成到PC中锌历，一塊連接到Internet上，一塊連接到后端服務器群的內部網絡上峦筒。
負載均衡器通常稱為四層交換機或七層交換機究西。四層交換機主要分析IP層及TCP/UDP層，實現(xiàn)四層流量負載均衡物喷。七層交換機除了支持四層負載均衡以外卤材，還有分析應用層的信息，如HTTP協(xié)議URI或Cookie信息峦失。
1扇丛、負載均衡分為L4 switch（四層交換），即在OSI的第4層工作尉辑，就是TCP層帆精。此種Load Balance不理解應用協(xié)議（如HTTP/FTP/MySQL等等）。例子：LVS隧魄，F(xiàn)5(一種負載均衡硬件很貴,用于大型有實力有錢的公司)卓练。
2、另一種負載均衡分為L7 switch（七層交換）购啄，OSI的最高層襟企，應用層。此時狮含，該Load Balancer能理解應用協(xié)議顽悼。例子： ?haproxy，MySQL Proxy辉川”眚 注意：上面的很多Load Balancer 既可以做四層交換，也可以做七層交換乓旗。
一般而言府蛇，硬件負載均衡在功能、性能上優(yōu)于軟件方式屿愚，不過成本昂貴汇跨。
負載均衡設備也常被稱為"四到七層交換機"，那么四層和七層兩者到底區(qū)別在哪里妆距？
第一穷遂，技術原理上的區(qū)別。
????????所謂四層負載均衡娱据，也就是主要通過報文中的目標地址和端口蚪黑，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
????????以常見的TCP為例忌穿，負載均衡設備在接收到第一個來自客戶端的SYN 請求時抒寂，即通過上述方式選擇一個最佳的服務器，并對報文中目標IP地址進行修改(改為后端服務器IP）掠剑，直接轉發(fā)給該服務器屈芜。TCP的連接建立，即三次握手是客戶端和服務器直接建立的朴译，負載均衡設備只是起到一個類似路由器的轉發(fā)動作井佑。在某些部署情況下，為保證服務器回包可以正確返回給負載均衡設備眠寿，在轉發(fā)報文的同時可能還會對報文原來的源地址進行修改躬翁。?
?????????所謂七層負載均衡，也稱為“內容交換”盯拱，也就是主要通過報文中的真正有意義的應用層內容姆另，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器坟乾。
????????以常見的TCP為例，負載均衡設備如果要根據真正的應用層內容再選擇服務器蝶防，只能先代理最終的服務器和客戶端建立連接(三次握手)后甚侣，才可能接受到客戶端發(fā)送的真正應用層內容的報文渠啤，然后再根據該報文中的特定字段践剂，再加上負載均衡設備設置的服務器選擇方式并齐，決定最終選擇的內部服務器蹦误。負載均衡設備在這種情況下乙濒，更類似于一個代理服務器嘱腥。負載均衡和前端的客戶端以及后端的服務器會分別建立TCP連接殿雪。所以從這個技術原理上來看钧栖，七層負載均衡明顯的對負載均衡設備的要求更高嘿悬，處理七層的能力也必然會低于四層模式的部署方式实柠。?
第二，應用場景的需求善涨。
????????七層應用負載的好處窒盐，是使得整個網絡更"智能化"。例如訪問一個網站的用戶流量钢拧，可以通過七層的方式蟹漓，將對圖片類的請求轉發(fā)到特定的圖片服務器并可以使用緩存技術；將對文字類的請求可以轉發(fā)到特定的文字服務器并可以使用壓縮技術源内。當然這只是七層應用的一個小案例葡粒，從技術原理上，這種方式可以對客戶端的請求和服務器的響應進行任意意義上的修改，極大的提升了應用系統(tǒng)在網絡層的靈活性嗽交。很多在后臺卿嘲，例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上，例如客戶請求中的Header重寫轮纫，服務器響應中的關鍵字過濾或者內容插入等功能腔寡。另外一個常常被提到功能就是安全性。網絡中最常見的SYN Flood攻擊掌唾，即黑客控制眾多源客戶端放前，使用虛假IP地址對同一目標發(fā)送SYN攻擊，通常這種攻擊會大量發(fā)送SYN報文糯彬，耗盡服務器上的相關資源凭语，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出撩扒，四層模式下這些SYN攻擊都會被轉發(fā)到后端的服務器上似扔；而七層模式下這些SYN攻擊自然在負載均衡設備上就截止，不會影響后臺服務器的正常運營搓谆。另外負載均衡設備可以在七層層面設定多種策略炒辉，過濾特定報文，例如SQL?Injection等應用層面的特定攻擊手段泉手，從應用層面進一步提高系統(tǒng)整體安全∏埽現(xiàn)在的7層負載均衡，主要還是著重于應用HTTP協(xié)議斩萌，所以其應用范圍主要是眾多的網站或者內部信息平臺等基于B/S開發(fā)的系統(tǒng)缝裤。 4層負載均衡則對應其他TCP應用，例如基于C/S開發(fā)的ERP等系統(tǒng)颊郎。?
四憋飞、負載均衡算法
一般來說負載均衡設備都會默認支持多種負載均衡分發(fā)策略
輪詢（RoundRobin）將請求順序循環(huán)地發(fā)到每個服務器。當其中某個服務器發(fā)生故障姆吭，AX就把其從順序循環(huán)隊列中拿出榛做，不參加下一次的輪詢，直到其恢復正常猾编。
比率（Ratio）：給每個服務器分配一個加權值為比例瘤睹，根椐這個比例，把用戶的請求分配到每個服務器答倡。當其中某個服務器發(fā)生故障轰传，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配瘪撇，直到其恢復正常获茬。
優(yōu)先權（Priority）：給所有服務器分組港庄，給每個組定義優(yōu)先權，將用戶的請求分配給優(yōu)先級最高的服務器組（在同一組內恕曲，采用預先設定的輪詢或比率算法鹏氧，分配用戶的請求）；當最高優(yōu)先級中所有服務器或者指定數量的服務器出現(xiàn)故障佩谣，AX將把請求送給次優(yōu)先級的服務器組把还。這種方式，實際為用戶提供一種熱備份的方式茸俭。
最少連接數（LeastConnection）：AX會記錄當前每臺服務器或者服務端口上的連接數吊履，新的連接將傳遞給連接數最少的服務器。當其中某個服務器發(fā)生故障调鬓，AX就把其從服務器隊列中拿出艇炎，不參加下一次的用戶請求的分配，直到其恢復正常腾窝。
最快響應時間（Fast Reponse time）：新的連接傳遞給那些響應最快的服務器缀踪。當其中某個服務器發(fā)生故障，AX就把其從服務器隊列中拿出虹脯，不參加下一次的用戶請求的分配驴娃，直到其恢復正常。
哈希算法( hash): 將客戶端的源地址循集，端口進行哈希運算托慨，根據運算的結果轉發(fā)給一臺服務器進行處理，當其中某個服務器發(fā)生故障暇榴，就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配蕉世，直到其恢復正常蔼紧。
基于數據包的內容分發(fā)：例如判斷HTTP的URL，如果URL中帶有.jpg的擴展名狠轻，就把數據包轉發(fā)到指定的服務器奸例。
五、健康檢查
健康檢查用于檢查服務器開放的各種服務的可用狀態(tài)向楼。
負載均衡設備一般會配置各種健康檢查方法查吊，例如Ping，TCP湖蜕，UDP逻卖，HTTP，F(xiàn)TP昭抒，DNS等评也。
????????Ping屬于第三層的健康檢查炼杖，用于檢查服務器IP的連通性，TCP/UDP屬于第四層的健康檢查盗迟，用于檢查服務端口的UP/DOWN坤邪，如果要檢查的更準確，就要用到基于7層的健康檢查罚缕，例如創(chuàng)建一個HTTP健康檢查艇纺，Get一個頁面回來，并且檢查頁面內容是否包含一個指定的字符串邮弹，如果包含黔衡，則服務是UP的，如果不包含或者取不回頁面肠鲫，就認為該服務器的Web服務是不可用（DOWN）的员帮。比如，負載均衡設備檢查到172.16.20.3這臺服務器的80端口是DOWN的导饲，負載均衡設備將不把后面的連接轉發(fā)到這臺服務器捞高，而是根據算法將數據包轉發(fā)到別的服務器。創(chuàng)建健康檢查時可以設定檢查的間隔時間和嘗試次數渣锦，例如設定間隔時間為5秒硝岗，嘗試次數為3，那么負載均衡設備每隔5秒發(fā)起一次健康檢查袋毙，如果檢查失敗型檀，則嘗試3次，如果3次都檢查失敗听盖，則把該服務標記為DOWN胀溺，然后服務器仍然會每隔5秒對DOWN的服務器進行檢查，當某個時刻發(fā)現(xiàn)該服務器健康檢查又成功了皆看，則把該服務器重新標記為UP仓坞。健康檢查的間隔時間和嘗試次數要根據綜合情況來設置，原則是既不會對業(yè)務產生影響腰吟，又不會對負載均衡設備造成較大負擔无埃。
六、會話保持
如何保證一個用戶的兩次http請求轉發(fā)到同一個服務器毛雇，這就要求負載均衡設備配置會話保持嫉称。
會話保持用于保持會話的連續(xù)性和一致性，由于服務器之間很難做到實時同步用戶訪問信息灵疮，這就要求把用戶的前后訪問會話保持到一臺服務器上來處理织阅。
????舉個例子，用戶訪問一個電子商務網站震捣，如果用戶登錄時是由第一臺服務器來處理的蒲稳，但用戶購買商品的動作卻由第二臺服務器來處理氮趋，第二臺服務器由于不知道用戶信息，所以本次購買就不會成功江耀。這種情況就需要會話保持剩胁，把用戶的操作都通過第一臺服務器來處理才能成功。當然并不是所有的訪問都需要會話保持祥国，例如服務器提供的是靜態(tài)頁面比如網站的新聞頻道昵观，各臺服務器都有相同的內容，這種訪問就不需要會話保持舌稀。
絕大多數的負載均衡產品都支持兩類基本的會話保持方式：源/目的地址會話保持和cookie會話保持啊犬，另外像hash，URL Persist等也是比較常用的方式壁查，但不是所有設備都支持觉至。基于不同的應用要配置不同的會話保持睡腿，否則會引起負載的不均衡甚至訪問異常语御。我們主要分析B/S結構的會話保持。
七席怪、基于B/S結構的應用：
????????對于普通B/S結構的應用內容应闯，例如網站的靜態(tài)頁面，可以不用配置任何的會話保持挂捻，但是對于一個基于B/S結構尤其是中間件平臺的業(yè)務系統(tǒng)來說碉纺，必須配置會話保持，一般情況下刻撒，我們配置源地址會話保持可以滿足需求骨田，但是考慮到客戶端可能有上述不利于源地址會話保持的環(huán)境，采用Cookie會話保持是一個更好的方式声怔。Cookie會話保持會把負載均衡設備選擇的Server信息保存在Cookie中發(fā)送到客戶端盛撑，客戶端持續(xù)訪問時，會把該Cookie帶來捧搞，負載均衡器通過分析Cookie把會話保持到之前選定的服務器。Cookie分為文件Cookie和內存cookie狮荔，文件cookie保存在客戶端計算機硬盤上胎撇，只要該cookie文件不過期，則無論是否重復關閉開放瀏覽器都能保持到同一臺服務器殖氏。內存Cookie則是把Cookie信息保存在內存中晚树，Cookie的生存時間從打開瀏覽器訪問開始，關閉瀏覽器結束雅采。由于現(xiàn)在的瀏覽器對Cookie都有一定默認的安全設置爵憎，有些客戶端可能規(guī)定不準使用文件Cookie慨亲，所以現(xiàn)在的應用程序開發(fā)多使用內存Cookie。
????????然而宝鼓，內存Cookie也不是萬能的刑棵，比如瀏覽器為了安全可能會完全禁用Cookie，這樣Cookie會話保持就失去了作用愚铡。我們可以通過Session-id來實現(xiàn)會話保持蛉签，即將session-id作為url參數或者放在隱藏字段<input type="hidden">中，然后分析Session-id進行分發(fā)沥寥。
????????另一種方案是：將每一會話信息保存到一個數據庫中碍舍。由于這個方案會增加數據庫的負載，所以這個方案對性能的提高并不好邑雅。數據庫最好是用來存儲會話時間比較長的會話數據片橡。為了避免數據庫出現(xiàn)單點故障，并且提高其擴展性淮野，數據庫通常會復制到多臺服務器上捧书，通過負載均衡器來分發(fā)請求到數據庫服務器上。
????????基于源/目的地址會話保持其實不太好用录煤，因為客戶可能是通過DHCP鳄厌，NAT或者Web代理來連接Internet的，其IP地址可能經常變換妈踊，這使得這個方案的服務質量無法保障了嚎。
????????NAT(Network Address Translation，網絡地址轉換):當在專用網內部的一些主機本來已經分配到了本地IP地址(即僅在本專用網內使用的專用地址)廊营，但現(xiàn)在又想和因特網上的主機通信(并不需要加密)時歪泳，可使用NAT方法。這種方法需要在專用網連接到因特網的路由器上安裝NAT軟件露筒。裝有NAT軟件的路由器叫做NAT路由器呐伞，它至少有一個有效的外部全球IP地址。這樣慎式，所有使用本地地址的主機在和外界通信時伶氢，都要在NAT路由器上將其本地地址轉換成全球IP地址，才能和因特網連接瘪吏。
八癣防、負載均衡項目需求分析
負載均衡方案應是在網站建設初期就應考慮的問題，不過有時隨著訪問流量的爆炸性增長掌眠，超出決策者的意料蕾盯，這也就成為不得不面對的問題。當我們在引入某種負載均衡方案乃至具體實施時蓝丙，像其他的許多方案一樣级遭，首先是確定當前及將來的應用需求望拖，然后在代價與收效之間做出權衡。
針對當前及將來的應用需求挫鸽，分析網絡瓶頸的不同所在说敏，我們就需要確立是采用哪一類的負載均衡技術，采用什么樣的均衡策略掠兄，在可用性像云、兼容性、安全性等等方面要滿足多大的需求蚂夕，如此等等迅诬。?
不管負載均衡方案是采用花費較少的軟件方式，還是購買代價高昂在性能功能上更強的第四層交換機婿牍、負載均衡器等硬件方式來實現(xiàn)侈贷，亦或其他種類不同的均衡技術，下面這幾項都是我們在引入均衡方案時可能要考慮的問題：
性能：性能是我們在引入均衡方案時需要重點考慮的問題等脂，但也是一個最難把握的問題俏蛮。衡量性能時可將每秒鐘通過網絡的數據包數目做為一個參數，另一個參數是均衡方案中服務器群所能處理的最大并發(fā)連接數目上遥，但是搏屑，假設一個均衡系統(tǒng)能處理百萬計的并發(fā)連接數，可是卻只能以每秒2個包的速率轉發(fā)粉楚，這顯然是沒有任何作用的辣恋。性能的優(yōu)劣與負載均衡設備的處理能力、采用的均衡策略息息相關模软，并且有兩點需要注意：一伟骨、均衡方案對服務器群整體的性能，這是響應客戶端連接請求速度的關鍵燃异；二携狭、負載均衡設備自身的性能，避免有大量連接請求時自身性能不足而成為服務瓶頸回俐。有時我們也可以考慮采用混合型負載均衡策略來提升服務器群的總體性能逛腿，如DNS負載均衡與NAT負載均衡相結合。另外仅颇，針對有大量靜態(tài)文檔請求的站點单默，也可以考慮采用高速緩存技術，相對來說更節(jié)省費用灵莲，更能提高響應性能；對有大量ssl/xml內容傳輸的站點殴俱，更應考慮采用ssl/xml加速技術政冻。
可擴展性：IT技術日新月異枚抵，一年以前最新的產品，現(xiàn)在或許已是網絡中性能最低的產品明场；業(yè)務量的急速上升汽摹，一年前的網絡，現(xiàn)在需要新一輪的擴展苦锨。合適的均衡解決方案應能滿足這些需求逼泣，能均衡不同操作系統(tǒng)和硬件平臺之間的負載，能均衡HTTP舟舒、郵件拉庶、新聞、代理秃励、數據庫氏仗、防火墻和 Cache等不同服務器的負載，并且能以對客戶端完全透明的方式動態(tài)增加或刪除某些資源夺鲜。
靈活性：均衡解決方案應能靈活地提供不同的應用需求皆尔，滿足應用需求的不斷變化。在不同的服務器群有不同的應用需求時币励，應有多樣的均衡策略提供更廣泛的選擇慷蠕。
可靠性：在對服務質量要求較高的站點，負載均衡解決方案應能為服務器群提供完全的容錯性和高可用性食呻。但在負載均衡設備自身出現(xiàn)故障時流炕，應該有良好的冗余解決方案，提高可靠性搁进。使用冗余時浪感，處于同一個冗余單元的多個負載均衡設備必須具有有效的方式以便互相進行監(jiān)控，保護系統(tǒng)盡可能地避免遭受到重大故障的損失饼问。
易管理性：不管是通過軟件還是硬件方式的均衡解決方案影兽，我們都希望它有靈活、直觀和安全的管理方式莱革，這樣便于安裝峻堰、配置、維護和監(jiān)控盅视，提高工作效率捐名，避免差錯。在硬件負載均衡設備上闹击，目前主要有三種管理方式可供選擇：一镶蹋、命令行接口（CLI：Command Line Interface），可通過超級終端連接負載均衡設備串行接口來管理，也能telnet遠程登錄管理贺归，在初始化配置時淆两，往往要用到前者；二拂酣、圖形用戶接口（GUI：Graphical User Interfaces）秋冰，有基于普通web頁的管理，也有通過Java Applet 進行安全管理婶熬，一般都需要管理端安裝有某個版本的瀏覽器剑勾；三、SNMP（Simple Network Management Protocol赵颅，簡單網絡管理協(xié)議）支持虽另，通過第三方網絡管理軟件對符合SNMP標準的設備進行管理
注:文章如有疑問或錯誤之處,請留言評論指出,必將學習之.
