程式設計界的國小生
- 一、是什麼
- 二、那還要nginx幹嘛？
- 三、LVS術語
- 四、三種模型
-
- 0、補充：路由器
- 1、D-NAT
- 2、DR
- 3、TUN
- 4、三種模型對比
- 五、LVS負載均衡算法
- 六、個人公衆号
一、是什麼
負載均衡排程器。那麼和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後面三個tomcat等容器叢集，挂了一台，nginx會自動放棄掉這台，将請求打到其他機器。而lvs不行，lvs發現這台挂了，請求還會給他，這時候就會造成不友好的情況，是以結合使用，各自發揮各自的優點。
上面那段話看得懂的話就不用看下面這堆詳細的解釋，但個人建議看下，萬一你不會呢？
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碼農社群】