一、是什麼
負載均衡調度器。那麼和nginx區別是啥？
- 首先nginx是七層的，lvs是四層的（網絡七層，不是此篇重點，不多BB）
- nginx每個請求都需要與客戶端握手，且服務端返回響應後需要經過nginx轉發到客戶端，也就是請求和響應都需要經過nginx
- lvs不需要和客戶端握手，就是一個轉發器，請求來了我就轉發到後面真實服務器，LVS的DR模式，可以直接讓後端真實服務器的響應打回到客戶端，而不需要再次經過LVS一次。
二、那還要nginx幹嘛？
首先我認爲lvs和nginx是可以共存的。而不是單打獨鬥，當然單打獨鬥也沒毛病，但是不存在替代互斥的關係。
lvs跟nginx一起用的場景，我是這麼理解的：只有併發極其大的情況下才需要lvs， 併發太大，nginx可能壓力會大（因爲他每次都需要和client握手），這時候nginx前面掛一層lvs來幫nginx減輕負擔，然後nginx做tomcat等容器的負載均衡。各自展現各自的優點，共同辦事。
上面那段話看得懂的話就不用看下面這堆詳細的解釋，但個人建議看下，萬一你不會呢？
nginx用來做http的反向代理，通過配置upsteam實現http請求的負載均衡異步轉發。如果一個服務器請求失敗，立即切換到其他服務器，直到請求成功或者最後一臺服務器失敗爲止。簡直就是集羣的利器。
lvs採用的是同步請求轉發的策略。
同步轉發？？？異步轉發？？？
同步轉發是在lvs服務器接收到請求之後，立即redirect到一個後端服務器，由客戶端直接和後端服務器建立連接。而不是客戶端和lvs進行握手建立連接。
異步轉發是nginx與客戶端建立連接，保持客戶端連接的同時，發起一個相同內容的新請求到後端，等後端返回結果給nginx後，再由nginx將後端返回的結果返回給客戶端。
小結：nginx是所有的請求和響應流量都會經過nginx；而lvs是僅請求流量經過lvs的網絡，響應流量由後端服務器的網絡返回給客戶端。
所以併發極大的情況下，nginx的網絡帶寬就成了一個巨大的瓶頸。
但是僅僅使用lvs作爲負載均衡的話，一旦後端接受到請求的服務器出了問題，那麼這次請求就失敗了。但是如果在lvs的後端在添加一層nginx（多個），每個nginx後端再有幾臺應用服務器，那麼結合兩者的優勢，既能避免單nginx的流量集中瓶頸，又能避免單lvs時一錘子買賣的問題（nginx轉發失敗後會找下一臺服務器繼續轉發請求）。
三、LVS術語
- DS：Director Server。前端負載均衡的服務器。比如LVS等。
- RS：Real Server。後端真實的工作服務器，比如tomcat等。
- VIP：Virtual IP。虛擬IP，是客戶端請求的目標的IP地址，比如LVS集羣，肯定多個IP，但是客戶端只會請求其中一個固定IP，這個就是VIP。
- DIP：Director Server IP，一般用於和後端真實的工作服務器通信的。
- RIP：Real Server IP，後端真實的工作服務器的IP。
- CIP：Client IP，客戶端IP，通常直接和VIP交互。
CIP -> VIP -> DIP -> RIP
四、三種模型
不多BB，全在圖上了。
0、補充：路由器
1、D-NAT
2、DR
解決D-NAT的請求響應都走DS，造成瓶頸問題。DR只有請求走DS，響應直接打到client，不在經過DS。
LVS DR原理等流程都在圖上了。
3、TUN
4、三種模型對比
- 是否需要VIP和realserver在同一網段
DR模式因爲只修改包的MAC地址，需要通過ARP廣播找到realserver，所以VIP和realserver必須在同一個網段，也就是說DR模式需要先確認這個IP是否只能掛在這個LVS下面；其他模式因爲都會修改目的地址爲realserver的IP地址，所以不需要在同一個網段內
- 三種模式的性能比較
DR模式、IP TUN模式都是在包進入的時候經過LVS，在包返回的時候直接返回給client；所以二者的性能比NAT高
但TUN模式更加複雜，所以性能不如DR
性能比較：DR>TUN>NAT
五、LVS負載均衡算法
- 輪叫調度 rr
均等地對待每一臺服務器，不管服務器上的實際連接數和系統負載
- 加權輪叫 wrr
調度器可以自動問詢真實服務器的負載情況，並動態調整權值
- 最少鏈接 lc
動態地將網絡請求調度到已建立的連接數最少的服務器上，如果集羣真實的服務器具有相近的系統性能，採用該算法可以較好的實現負載均衡
- 加權最少鏈接 wlc
調度器可以自動問詢真實服務器的負載情況，並動態調整權值，帶權重的誰不幹活就給誰分配，機器配置好的權重高
- 基於局部性的最少連接調度算法 lblc
這個算法是請求數據包的目標 IP 地址的一種調度算法，該算法先根據請求的目標 IP 地址尋找最近的該目標 IP 地址所有使用的服務器，如果這臺服務器依然可用，並且有能力處理該請求，調度器會盡量選擇相同的服務器，否則會繼續選擇其它可行的服務器
- 複雜的基於局部性最少的連接算法 lblcr
記錄的不是要給目標 IP 與一臺服務器之間的連接記錄，它會維護一個目標 IP 到一組服務器之間的映射關係，防止單點服務器負載過高。
- 目標地址散列調度算法 dh
該算法是根據目標 IP 地址通過散列函數將目標 IP 與服務器建立映射關係，出現服務器不可用或負載過高的情況下，發往該目標 IP 的請求會固定發給該服務器。
- 源地址散列調度算法 sh
與目標地址散列調度算法類似，但它是根據源地址散列算法進行靜態分配固定的服務器資源。
- 最少期望延遲 sed
不考慮非活動鏈接，誰的權重大，優先選擇權重大的服務器來接收請求，但權重大的機器會比較忙
- 永不排隊 nq
無需隊列，如果有realserver的連接數爲0就直接分配過去
六、個人公衆號
微信公衆號【Java碼農社區】
