開篇

我們分析了Go原生網絡模型以及部分源碼，絕大部分場景下(99%)，使用原生netpoll已經足夠了。

但是在一些海量并發連接下，原生netpoll會為每一個連接都開啟一個goroutine處理，也就是1千萬的連接就會創建一千萬個goroutine。

這就給了這些特殊場景下的優化空間，這也是像gnet和cloudwego/netpoll誕生的原因之一吧。

本質上他們的底層核心都是一樣的，都是基于epoll(linux)實現的。只是事件發生后，每個庫的處理方式會有所不同。

本篇文章主要分析gnet的。至于使用姿勢就不發了，gnet有對應的demo庫，可以自行體驗。

架構

直接引用gnet官網的一張圖：

gnet采用的是『主從多 Reactors』。也就是一個主線程負責監聽端口連接，當一個客戶端連接到來時，就把這個連接根據負載均衡算法分配給其中一個sub線程，由對應的sub線程去處理這個連接的讀寫事件以及管理它的死亡。

下面這張圖就更清晰了。

核心結構

我們先解釋gnet的一些核心結構。

engine就是程序最上層的結構了。

• ln對應的listener就是服務啟動后對應監聽端口的監聽器。
• lb對應的loadBalancer就是負載均衡器。也就是當客戶端連接服務時，負載均衡器會選擇一個sub線程，把連接交給此線程處理。
• mainLoop 就是我們的主線程了，對應的結構eventloop。當然我們的sub線程結構也是eventloop。結構相同，不同的是職責。主線程負責的是監聽端口發生的客戶端連接事件，然后再由負載均衡器把連接分配給一個sub線程。而sub線程負責的是綁定分配給他的連接(不止一個)，且等待自己管理的所有連接后續讀寫事件，并進行處理。

接著看eventloop。

• netpoll.Poller:每一個 eventloop都對應一個epoll或者kqueue。
• buffer用來作為讀消息的緩沖區。
• connCoun記錄當前eventloop存儲的tcp連接數。
• udpSockets和connetcions分別管理著這個eventloop下所有的udp socket和tcp連接，注意他們的結構map。這里的int類型存儲的就是fd。

對應conn結構。

這里面有幾個字段介紹下：

• buffer:存儲當前conn對端(client)發送的最新數據，比如發送了三次，那個此時buffer存儲的是第三次的數據,代碼里有。
• inboundBuffer:存儲對端發送的且未被用戶讀取的剩余數據，還是個Ring Buffer。
• outboundBuffer:存儲還未發送給對端的數據。(比如服務端響應客戶端的數據，由于conn fd是不阻塞的，調用write返回不可寫的時候，就可以先把數據放到這里)

conn相當于每個連接都會有自己獨立的緩存空間。這樣做是為了減少集中式管理內存帶來的鎖問題。使用Ring buffer是為了增加空間的復用性。

整體結構就這些。

核心邏輯

當程序啟動時，

會根據用戶設置的options明確eventloop循環的數量，也就是有多少個sub線程。再進一步說，在linux環境就是會創建多少個epoll對象。

那么整個程序的epoll對象數量就是count(sub)+1(main Listener)。

上圖就是我說的，會根據設置的數量創建對應的eventloop,把對應的eventloop 注冊到負載均衡器中。

當新連接到來時，就可以根據一定的算法(gnet提供了輪詢、最少連接以及hash)挑選其中一個eventloop把連接分配給它。

我們先來看主線程，(由于我使用的是mac,所以后面關于IO多路復用，實現部分就是kqueue代碼了，當然原理是一樣的)。

Polling就是等待網絡事件到來，傳遞了一個閉包參數，更確切的說是一個事件到來時的回調函數，從名字可以看出，就是處理新連接的。

至于Polling函數。

邏輯很簡單，一個for循環等待事件到來，然后處理事件。

主線程的事件分兩種：

一種是正常的fd發生網絡連接事件。

一種是通過NOTE_TRIGGER立即激活的事件。

通過NOTE_TRIGGER觸發告訴你隊列里有task任務，去執行task任務。

如果是正常的網絡事件到來，就處理閉包函數，主線程處理的就是上面的accept連接函數。

accept連接邏輯很簡單，拿到連接的fd。設置fd非阻塞模式(想想連接是阻塞的會咋么樣?),然后根據負載均衡算法選擇一個sub 線程，通過register函數把此連接分配給它。

register做了兩件事，首先需要把當前連接注冊到當前sub 線程的epoll or kqueue 對象中,新增read的flag。

接著就是把當前連接放入到connections的map結構中 fd->conn。

這樣當對應的sub線程事件到來時，可以通過事件的fd找到是哪個連接，進行相應的處理。

如果是可讀事件。

到這里分析差不多就結束了。

總結

在gnet里面，你可以看到，基本上所有的操作都無鎖的。

那是因為事件到來時，采取的都是非阻塞的操作，且是串行處理對應的每個fd(conn)。每個conn操作的都是自身持有的緩存空間。同時處理完一輪觸發的所有事件才會循環進入下一次等待，在此層面上解決了并發問題。

當然這樣用戶在使用的時候也需要注意一些問題，比如用戶在自定義EventHandler中，如果要異步處理邏輯，就不能像下面這樣開一個g然后在里面獲取本次數據。

而應該先拿到數據，再異步處理。

issues上有提到，連接是使用map[int]*conn存儲的。gnet本身的場景就是海量并發連接，內存會很大。進而big map存指針會對 GC造成很大的負擔，畢竟它不像數組一樣，是連續內存空間，易于GC掃描。

還有一點，在處理buffer數據的時候，就像上面看到的，本質上是將buffer數據copy給用戶一份，那么就存在大量copy開銷,在這一點上，字節的netpoll實現了Nocopy Buffer，改天研究一下。