一、lvs的型別：
（1）lvs-nat：network address translation
請求：client：cip，vip — director : cip,vip 轉化director：dip，rip—real server：dip，rip
響應：real server：rip，dip –director: rip,dip 轉化為：director：vip，cip—client：vip，cip
特性：
1、rs應用使用私有位址；rs的閘道器必須指向dip；
2、請求和響應都要經過director；高負載場景中，director易成為效能瓶頸；（3-4萬併發量還是問題不大，日上億條訪問記錄）
3、支援埠對映；
4、rs可以使用任意os；
5、rs的rip跟director的dip必須在乙個網段
6、director的vip必須為公網ip；
（2）lvs-dr 請求經過dr，而響應為real server直接相應。dr模式是通過改寫請求報文的目標mac位址，將請求發給真實伺服器的，而真實伺服器響應後的處理結果直接返回給客戶端使用者。同tun模式一樣，dr模式可以極大的提高集群系統的伸縮性。而且dr模式沒有ip隧道的開銷，對集群中的真實伺服器也沒有必要必須支援ip隧道協議的要求。但是要求排程器lb與真實伺服器rs都有一塊網絡卡連線到同一物理網段上，必須在同乙個區域網環境。
dr模式是網際網路使用比較多的一種模式。
特性：
1、保證前端路由將目標位址為vip的報文統統發往directory，而不能是rs；
解決方案：
問題：未必有路由操作許可權
(2) aprtables
(3) 修改rs上核心引數，將rs上的vip配置在lo介面的別名上，並限制其不能響應對vip位址解析請求；
2、rs可以使用私有位址；但也可以使用公網位址，此時可通過網際網路通過rip對其直接訪問；
3、rs跟directory必須在同一物理網路中；
4、請求報文經由director，但響應報文必須不能經過director；
5、不支援埠對映；
6、rs可以是大多數常見的os；
7、rs的閘道器絕不允許指向dip；
（3）lvs-tun 請求經過dr
virtual server via ip tunneling模式:採用nat模式時，由於請求和響應的報文必須通過排程器位址重寫，當客戶請求越來越多時，排程器處理能力將成為瓶頸。為了解決這個問題，排程器把請求的報文通過ip隧道**到真實的伺服器。真實的伺服器將響應處理後的資料直接返回給客戶端。這樣排程器就只處理請求入站報文，由於一般網路服務應答資料比請求報文大很多，採用vs/tun模式後，集群系統的最大吞吐量可以提高10倍。
vs/tun的工作流程圖如下所示，它和nat模式不同的是，它在lb和rs之間的傳輸不用改寫ip位址。而是把客戶請求包封裝在乙個ip tunnel裡面，然後傳送給rs節點伺服器，節點伺服器接收到之後解開ip tunnel後，進行響應處理。並且直接把包通過自己的外網位址傳送給客戶不用經過lb伺服器。
tunneling不修改請求ip首部，而是用過原有的ip首部（cipvip）之外，再封裝乙個ip首部（diprip）
特性:
1、rip、vip、dip全部是公網位址；
2、rs的閘道器不會也不可能指向dip；
3、請求報文經由director，但響應報文必須不能經過director；
4、不支援埠對映；
5、rs的os必須支援隧道功能；
（4）lvs-fullnat
請求：cip,vipdip,rip
響應：rip,dipvip,cip
特性:
2、rs接收到的請求報文的源位址為dip，因此要響應給dip
3、請求報文和響應報文都必須經由director；
4、支援埠對映機制；
5、認識可以使用任意os；
二、http: stateless
（1）session保持：
session繫結：
cookie ：通用應用程式插入cookie
（2）session集群：每個主機有全部的session，各主機session隨時同步session，浪費網路記憶體資源。全down機，保證session持久化。
（3）session伺服器：不在本地維護session，所有session存session到session伺服器上。redis複製集群。
三、lvs scheduler：首次分配起點分配，二次分配結果公平
靜態方法：僅根據演算法本身進行排程；起點公平；
（1）rr：round robin，輪調
（2）wrr：weighted rr, 能者多勞，當前權重/所有權重之和；
（3）sh: source hash, 實現session保持的機制；將來自於同乙個ip的請求始終排程至同一rs；損害負載均衡效果。
（4）dh：destination hash, 將對同乙個目標的請求始終發往同乙個rs；
動態方法：根據演算法及各rs的當前負載狀態進行排程；結果公平；
overhead=
（5）lc：least connection
overhead=active*256+inactive
（6）wlc: weighted lc 第乙個總算在乙個rs上面，沒有權重
overhead=(active*256+inactive)/weight
（7）sed: shortest expection delay 保證第一次總是在權重最高的rs上面，但是開始不均勻。
overhead=(active+1)*256/weight
（8）nq：never queue 保證第一次每次一次，然後再sed排程
sed演算法的改進；無需佇列。如果有台 realserver的連線數＝0就直接分配過去，不需要在進行sed運算
（9）lblc：locality-based lc，即為動態的dh演算法；
正向**情形下的cache server排程；
這種演算法本質就是
lc演算法或理解為
wlc演算法。但是該演算法的特性是，注意實現目標是要和靜態排程演算法中的
dh演算法一樣，用於將同一類請求
**到乙個固定節點，因此常用於快取伺服器的場景。但是
dh演算法因為是靜態排程演算法，不會考慮後端（快取）伺服器的當前連線數，但
lblc
就是在dh
演算法的基礎上考慮後端伺服器當前的連線數。
如果（快取）伺服器使用了集群（如
memcached
的主主複製），因為所有節點的快取資料都相同，因此要使用負載均衡演算法來實現請求按照當
前伺服器的負載進行**。而如果後端的每個快取伺服器的內容不同，使用
lblc
就會破壞命中率並且導致多個快取節點快取了相同的資料，因此為了提高快取命中率以及防止多個節點快取相同的資料，一般就不採用
lblc
而直接採用dh。
（10）lblcr：locality-based least-connection with replication，帶複製功能的lblc演算法；
lvs基礎理論
一 lvs的型別 1 lvs nat network address translation 請求 client cip，vip director cip,vip 轉化director dip，rip real server dip，rip 響應 real server rip，dip direct...
基礎理論（四）
1.簡述python中物件的記憶體是如何管理的 2.簡述類和物件的概念及類繼承的特點 3.簡述python如何操作 mysql,用到什麼包 寫出具體的增刪改查語句 4.簡述scrapy爬蟲的資料流向過程 5.網路七層協議都是哪七層?6.scrapy中如何設定隨機請求頭 隨機 寫出具體步驟 需要什麼配...
vue基礎理論
2 前端框架與庫的區別?kfc的世界裡,庫就是乙個小 框架就是全家桶 上的不同 3 vue起步 vue的檔案介紹 4 插值表示式 注意 必能直接寫語句 可以用於頁面中簡單粗暴的除錯 注意 必須在data這個函式中返回的物件中宣告 比如在angular中 以ng 開頭的就叫做指令 在vue中 以v 開...