用 Go 基于 epoll 实现一个最小化 IO 库

[RememberCurry]

目前 Go 圈有很多款异步的网络框架:

• https://github.com/tidwall/evio
• https://github.com/lesismal/nbio
• https://github.com/panjf2000/gnet
• https://github.com/cloudwego/netpoll
• .......

排名不分先后。

这里面最早的实现是 evio 。evio 也存在一些问题，之前也写过evio文章介绍过。 其他比如 nbio 和 gnet 也写过一些源码分析。

为什么会出现这些框架？之前也提到过，由于标准库 netpoll 的一些特性:

• 一个 conn 一个 goroutine 导致利用率低
• 用户无法感知 conn 状态
• .....

这些框架在应用层上做了很多优化，比如:Worker Pool,Buffer,Ring Buffer,NoCopy......。

都分析了好几篇的代码了，那么咋么说也得自己动手搞一个来达成学习目的。

没错，这就是easyio的由来。

它是一个最小化的 IO 框架，只实现最核心的部分，加起来不超过 500 行代码。

也没有用户端上层应用的优化，且目前只实现了 linux 的 epoll ，以及只能运行 tcp 协议。

简单的 demo ，

服务端:

package main

import (
	"context"
	"fmt"
	"os"
	"os/signal"
	"syscall"

	"github.com/wuqinqiang/easyio"
)

var _ easyio.EventHandler = (*Handler)(nil)

type Handler struct{}

type EasyioKey struct{}

type Message struct{ Msg string }

var CtxKey EasyioKey

func (h Handler) OnOpen(c easyio.Conn) context.Context {
	return context.WithValue(context.Background(), CtxKey, Message{Msg: "helloword"})
}

func (h Handler) OnRead(ctx context.Context, c easyio.Conn) {
	_, ok := ctx.Value(CtxKey).(Message)
	if !ok {
		return
	}
	var b = make([]byte, 100)
	_, err := c.Read(b)
	if err != nil {
		fmt.Println("err:", err)
	}
	fmt.Println("[Handler] read data:", string(b))

	if _, err = c.Write(b); err != nil {
		panic(err)
	}
}

func (h Handler) OnClose(_ context.Context, c easyio.Conn) {
	fmt.Println("[Handler] closed", c.Fd())
}

func main() {
	e := easyio.New("tcp", ":8090",easyio.WithNumPoller(4), easyio.WithEventHandler(Handler{}))

	if err := e.Start(); err != nil {
		panic(err)
	}

	defer e.Stop()

	c := make(chan os.Signal, 1)
	signal.Notify(c, syscall.SIGTERM, syscall.SIGQUIT, syscall.SIGINT)
	<-c
}

上面的代码，初始化一个 easyio ，启动一个 tcp 服务，监听端口 8090 ，options 里面设置 epoll 的数量，以及设置事件处理器。

当一个新连接到来时会回调 OnOpen 函数，此时你可以设置自定义的 ctx ，那么当对应连接读事件到来 OnRead 回调，你可以拿到之前设置的 ctx ，调用 conn.Read 读取数据，且通过 Write 向对端写数据。

这里需要注意的是，一个连接如果数据没读完，当 OnRead 执行结束，下一轮会继续触发回调代码，因为底层 epoll 采用的是 LT 触发方式。

简单的客户端

package main

import (
	"fmt"
	"net"
	"os"
	"os/signal"
	"syscall"
)

func main() {
	conn, err := net.Dial("tcp", ":8090")
	if err != nil {
		panic(err)
	}
	n, err := conn.Write([]byte("hello world"))
	if err != nil {
		panic(err)
	}

	go func() {
		b := make([]byte, 100)
		if n, err = conn.Read(b); err != nil {
			panic(err)
		}
		fmt.Println("read data:", n, string(b))
	}()

	defer conn.Close()

	ch := make(chan os.Signal, 1)
	signal.Notify(ch, syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT)

	<-ch
}

源码地址:https://github.com/wuqinqiang/easyio

[midknight]

有点意思，mark 一下

[julyclyde]

那为啥不去改进标准库呢？

这些年，各种“yet another”已经太多了。绝大多数都没长久的生命力

[hankai17]

go 用的少 有些疑问

"一个 conn 一个 goroutine 导致利用率低"
这个应该是优点吧 写起来方便 没看过 go 的协程 按理说性能不会太低吧

"用户无法感知 conn 状态"
同上 回调用起来不方便

[RememberCurry]

@julyclyde
我上面说了，
> 都分析了好几篇的代码了，那么咋么说也得自己动手搞一个来达成学习目的。

[RememberCurry]

@hankai17 海量连接情况下一个连接一个 g 并不划算

[julyclyde]

@RememberCurry 学习是目的，“单独搞一个”是手段，这完全两码事
如果贡献到标准库，你的作品还能多活几年

[RememberCurry]

@julyclyde 你说的都对。

[lindt99cocoa]

@hankai17 中国特色 go 协程问题

[codehz]

3202 年是不是可以用上 io uring 了（

[RememberCurry]

@codehz 俺不会，等俺学学😭

[z3phyr]

2023 年还在写回调，无异于开历史倒车

[matrix1010]

io 圈好卷。有没有人写 cache 框架跟我 pk 一下

[lesismal]

支持 OP 一下！

[lesismal]

> 2023 年还在写回调，无异于开历史倒车

@z3phyr
试试我这个，http 基本兼容标准库，http 和 websocket 来消息时都是可以写同步代码的。
https://github.com/lesismal/nbio

[lesismal]

> 3202 年是不是可以用上 io uring 了（

@codehz 单就网络 io 这块，不同场景下 io uring 、epoll 性能好像是各有优劣，并不是所有情况都一边倒，所以综合网络库 epoll 有历史加持、足够了。特定场景的话倒是可以考虑定向优化

[fgwmlhdkkkw]

脱裤子放屁，多此一举。

[Nazz]

@julyclyde 标准库你想改就能改吗

[Nazz]

@matrix1010 来和我们 pk
https://github.com/lesismal/go-websocket-benchmark

[sunny1688]

这样说的话，那我也来发一下我实现的轮子吧~~
netman： https://github.com/ikilobyte/netman

支持 TCP 、UDP 、WebSocket 、同时 TCP 支持路由模式

[tyrantZhao]

上 iouring

[RememberCurry]

我花了一个小时，仔细研读了社区条款以及一些法律文献，反复的把自己上述的文字重新编排组合，生怕遗漏一丝自己犯罪的细节，头上的汗水止不住地往下流，双手也不停地颤抖，可还是没有看到一丝犯罪，割菜，吹牛逼的行为，

可，评论区的一些评论我实在看不懂～

[matrix1010]

@Nazz 卷不动了，光搞 cache 就很费脑细胞了

[Nazz]

@z3phyr IO 异步，业务逻辑同步，没什么影响

[fds]

@julyclyde #2 标准库不可能接受这种异步的实现方式。go 标准都是用同步写逻辑的。

[fds]

op 不要灰心，大部分不需要连上万客户端的场景确实没必要这样优化，但我确实遇到过需要的情况。我当时是先试了 https://github.com/panjf2000/gnet 后来用的是 https://github.com/xtaci/gaio 但结果跑了一个月遇到了一次死锁，运维直接重启了，也没日志，公司当时还有别的事要忙，就没继续改进。

[fds]

@lesismal #14 哇，大佬✨ nbio 在 windows 下能支持 iocp 吗？不过我看 issue 里都没人提耶，看来需求不大…… 我就是问问哈，不是要大佬做哈，给大佬跪一个先🧎‍♂️。

[lesismal]

@fds
> 标准库不可能接受这种异步的实现方式。go 标准都是用同步写逻辑的。

标准库底层是非阻塞 io ，net.Conn 给用户提供阻塞接口 Read/Write ，用户需要主动 Read
nbio 底层也是非阻塞 io ，nbio 的 http/websocket nonblocking 模式下给用户提供的是非阻塞接口 Write ，用户不需要主动 Read 。nbio 基本兼容标准库，用户基于 nbio 可以像写标准库 http 一样，少量不兼容比如涉及 io.Copy ，其他的普通功能，只要把 io 替换成 nbio 就可以了、业务代码都不需要改，gin/echo 之类的也都能轻松用 nbio 替换 std http server 。
代码看下就能用了：
https://github.com/lesismal/nbio-examples/blob/master/http/server/server.go
https://github.com/lesismal/nbio-examples/blob/master/http_with_other_frameworks/gin_server/gin_server.go

> op 不要灰心，大部分不需要连上万客户端的场景确实没必要这样优化，但我确实遇到过需要的情况。我当时是先试了 > https://github.com/panjf2000/gnet 后来用的是 https://github.com/xtaci/gaio 但结果跑了一个月遇到了一次死锁，> 运维直接重启了，也没日志，公司当时还有别的事要忙，就没继续改进。

来吧，用 nbio ，还有救：
https://github.com/lesismal/nbio

这里有百万连接 websocket 的：
https://github.com/lesismal/go-websocket-benchmark

[lesismal]

@fds #26 windows 只为方便开发。。打死我也不会去支持 iocp 了，哈哈哈，太难搞了

[julyclyde]

@Nazz 能不能改是看你写的好不好的，而不是看你是不是名人的

[Nazz]

@RememberCurry 自己觉得有意义就好

[mindddd]

@z3phyr 此话怎讲，请细说

[zhaohua]

我一直不太理解，为啥 go 要上 epoll ，原生的 goroutine 在绝大多数场景下都没有性能问题，性能要求高的话可以上 rpc connect 复用。 感觉是 java 转过去的人卷的。

[lesismal]

> 可，评论区的一些评论我实在看不懂～

你可能还不知道吧，以前只是站着说话不腰疼，现在是躺着说话他也不腰疼呐

[kkocdko]

我想说楼主自己写着玩没问题，我也喜欢整天搓这类底层小玩具。

但是楼主为了推广自己的玩具，不惜妄顾事实，说出“一个 conn 一个 goroutine 导致利用率低”这种笑话，那就没必要说什么“评论实在看不懂”了。

退一万步讲，在超大流量的负载均衡需求下才会有这种对极限性能的追求，这固然很酷，但是大部分场景都不会根据 plain text 跑分来做选型，这并不是性能瓶颈。

https://www.techempower.com/benchmarks/#section=test&runid=f35979a9-4e5e-41db-9ba2-9790167667e9&test=plaintext

[lysS]

目的就是一个连接对应一个协程，从而避免写异步代码。话说哪些异步回调有什么用？其实很难在中间插入什么逻辑的

[Nazz]

@kkocdko
1. 海量连接不等于超大流量
2. 海量连接场景下使用标准网络库会耗费大量内存，goroutine 调度性能下降. 很明显，reactor 模式能节省 read_buffer_size * num_connections 的内存，以及海量 goroutine 的栈内存。
3. op 没放任何压测数据.

[wkong]

我也基于上面大佬们的思想开发了我的单机百万通用实时通讯服务，感兴趣可以 star 下

https://github.com/WuKongIM/WuKongIM

[RememberCurry]

@wkong 发现已经 star 过这个项目了，哈哈