Gnet 解析 Go 网络库 一篇学会

开篇

咱们剖析了Go原生网络模型以及局部源码，绝大局部场景下(99%)，经常使用原生netpoll曾经足够了。

然而在一些海量并发衔接下，原生netpoll会为每一个衔接都开启一个goroutine处置，也就是1千万的衔接就会创立一千万个goroutine。

这就给了这些不凡场景下的提升空间，这也是像gnet和cloudwego/netpoll降生的要素之一吧。

实质上他们的底层外围都是一样的，都是基于epoll(linux)成功的。只是事情出现后，每个库的处置形式会有所不同。

本篇文章关键剖析gnet的。至于经常使用姿态就不发了，gnet有对应的demo库，可以自行体验。

架构

间接援用gnet官方的一张图：

gnet驳回的是『主从多 Reactors』。也就是一个主线程担任监听端口衔接，当一个客户端衔接来到时，就把这个衔接依据负载平衡算法调配给其中一个sub线程，由对应的sub线程去处置这个衔接的读写事情以及治理它的死亡。

上方这张图就更明晰了。

外围结构

咱们先解释gnet的一些外围结构。

engine就是程序最下层的结构了。

接着看eventloop。

对应conn结构。

这外面有几个字段引见下：

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，改天钻研一下。