負載均衡篇 LVS初探一

對於負載均衡器而言，可以按照網路層次劃分來分類，如下圖：

位於第二層的交換機和第三層的路由器也可以作為負載均衡，但是我們接下去提到的都是指應用側的負載均衡，而不是路由側的負載均衡。

網路層和資料鏈路層負責資料**，只不過真正傳輸中是以資料鏈路層為實際傳輸層，網路層起到引導的作用。這是因為網路中負責傳輸的硬體網絡卡，網絡卡的mac位址是網路種真正的實體地址，而ip位址只是邏輯上的位址，理解這一點很重要，後文會再次提到。

基於分工協作的考慮，應用側的負載均衡當然是由傳輸層或者應用層去實現比較好，而

二、三層專注於路由**即可。

有人說lvs應該屬於三層的負載均衡，有的說屬於四層的負載均衡，較真起來意義不大，但是可以從如下的思路來理解。

lvs 屬於應用側的負載均衡，要**的必定是第四層傳輸層的資訊。如果**的是網路層的資訊，那麼tcp連線三次握手請求，網路層無法判斷這些請求是否屬於握手的，所以只能按照設定好的均衡規則去**三個握手資料報。

從這一點來看，lvs工作在四層。

但是，以後我們接觸到 lvs **實現原理時，會發現它工作在網路層，都是對ip報文的修改。

（負責**的）因為所有的操作都是在linux作業系統核心空間中將完成的，它的排程開銷很小，所以它具有很高的吞吐率。

by：章文嵩-linux伺服器集群系統（二）

這裡有兩個關鍵問題需要回答，即：

這裡說的核心指的是作業系統的核心。

作業系統和cpu共同制定了一套機制，該機制有幾個重要的點：

基於這種機制，程序看到的記憶體中也就包括了作業系統核心占用的記憶體塊。

核心占用的記憶體塊，不能被使用者程序直接訪問，相當於這塊空間cpu對其設定了等級保護。

其次，cpu 提供乙個syscall的指令，表示這是系統呼叫指令。系統呼叫，就是系統核心對外暴露的api介面，應用程序通過 syscall 指令控制cpu去執行相關api的指令，此時，就進入了核心態的環境，cpu執行在ring0級別，去執行核心已經制定好的指令。

這一過程，相當於應用程序間接的通過系統呼叫介面訪問到了記憶體塊中屬於核心的部分。

那麼，從使用者態轉到核心態多了哪些開銷呢？

雖然差別不大，但是扛不住量大，隨著頻繁的切換狀態，排程開銷自然會變高。

由於網路請求都屬於i/o請求，應用程式都要經過系統呼叫才可以進行正常的互動，那麼就不可避免地多了許多狀態切換地排程開銷。

因為 lvs 由兩段**組成：ipvsadm 和 ipvs，其中

linux2.4核心以後地版本中，已經包括了ipvs了。所以，該真正實現排程地模組就執行在核心態，而避免了和使用者態之間的頻繁切換。收到網路i/o中斷後，直接在核心空間完成即可。

經包括了ipvs了。所以，該真正實現排程地模組就執行在核心態，而避免了和使用者態之間的頻繁切換。收到網路i/o中斷後，直接在核心空間完成即可。

下篇文章，我們對lvs的工作機制進行學習。

負載均衡篇 LVS初探 一