Go 原生net库的问题

大连接内存占用

在上一篇文章Go 原生网络库 的源代码分析中我们可以看到，一般Go 的TCP 和HTTP 的程序都是每一个连接启动一个goroutine 去处理。在Go 的理念和设计中，goroutine 是廉价的，成千上万的goroutine 也是轻松的能够被创建，这点决不等同于进程或者线程。成千上万的goroutine 确实小case，但如果是上百万的连接呢，按照现在Go原生网络库 的goroutine-per-connection 模式意味着需要创建上百万的goroutine 去处理，实际上一个连接可能不止创建一个gorituine ，创建一个goroutine 要占用多少内存呢，答案是2kb～8kb （和操作系统以及Go 相关版本有关）不等，所以如果是数百万连接的话光内存占用可能会有十几个G之多，这也是一个不小的开销了。

调度压力问题

大量的goroutine 创建不仅仅会带来内存占用的问题，还会给Go runtime调度器的调度带来压力，从而导致调度效率的下降，最直接的表现就是吞吐率的下降、连接延时的增加。另外还记得在之前的Go原生网络库的文章中源码剖析中的sync.once epoller 嘛，也就是下面这一段：

serverInit.Do(runtime_pollServerInit)

这里serverInit 是一个sync.Once 类型，这么做可以保证只初始化一个epoll 实例。所以Go原生网络库 是一个单event loop ，也就是连接的处理（连接的建立和读写）和IO的处理都是被加入到一个epoller 实例的，在同一个event loop 里面处理，这样在海量连接的同时可能会导致性能瓶颈。

以上就是Go 原生net 库的问题，虽然平常很难遇到百万甚至千万级别的goroutine带来的调度压力和内存占用问题，即使遇到了最不济也是升级机器配置就可以解决，但真的遇到了这样的问题除了简单粗暴的升级机器配置之外还有什么别的办法呢？其实就是放弃Go原生net库的这种网络模式，采取更加高效的网络库模式，当然这也意味着放弃了Go煞费苦心封装后暴露给开发者稳定简单的网络API，需要开发者做更多额外的工作，付出更多的心智。下面就来看看有哪些高性能的网络库模式。

一些高性能网络库模式

Reactor 模式