Golang Go语言中用 Go 基于 epoll 实现一个最小化 IO 库
目前 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
}
Golang Go语言中用 Go 基于 epoll 实现一个最小化 IO 库
更多关于Golang Go语言中用 Go 基于 epoll 实现一个最小化 IO 库的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
有点意思,mark 一下
更多关于Golang Go语言中用 Go 基于 epoll 实现一个最小化 IO 库的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
那为啥不去改进标准库呢?
这些年,各种“yet another”已经太多了。绝大多数都没长久的生命力
go 用的少 有些疑问
"一个 conn 一个 goroutine 导致利用率低"
这个应该是优点吧 写起来方便 没看过 go 的协程 按理说性能不会太低吧
"用户无法感知 conn 状态"
同上 回调用起来不方便
我上面说了,
> 都分析了好几篇的代码了,那么咋么说也得自己动手搞一个来达成学习目的。
海量连接情况下一个连接一个 g 并不划算
学习是目的,“单独搞一个”是手段,这完全两码事
如果贡献到标准库,你的作品还能多活几年
你说的都对。
中国特色 go 协程问题
3202 年是不是可以用上 io uring 了(
俺不会,等俺学学😭
2023 年还在写回调,无异于开历史倒车
io 圈好卷。有没有人写 cache 框架跟我 pk 一下
支持 OP 一下!
> 3202 年是不是可以用上 io uring 了(
单就网络 io 这块,不同场景下 io uring 、epoll 性能好像是各有优劣,并不是所有情况都一边倒,所以综合网络库 epoll 有历史加持、足够了。特定场景的话倒是可以考虑定向优化
脱裤子放屁,多此一举。
标准库你想改就能改吗
这样说的话,那我也来发一下我实现的轮子吧~~
netman: https://github.com/ikilobyte/netman
支持 TCP 、UDP 、WebSocket 、同时 TCP 支持路由模式
上 iouring
我花了一个小时,仔细研读了社区条款以及一些法律文献,反复的把自己上述的文字重新编排组合,生怕遗漏一丝自己犯罪的细节,头上的汗水止不住地往下流,双手也不停地颤抖,可还是没有看到一丝犯罪,割菜,吹牛逼的行为,
可,评论区的一些评论我实在看不懂~
卷不动了,光搞 cache 就很费脑细胞了
IO 异步,业务逻辑同步,没什么影响
#2 标准库不可能接受这种异步的实现方式。go 标准都是用同步写逻辑的。
op 不要灰心,大部分不需要连上万客户端的场景确实没必要这样优化,但我确实遇到过需要的情况。我当时是先试了 https://github.com/panjf2000/gnet 后来用的是 https://github.com/xtaci/gaio 但结果跑了一个月遇到了一次死锁,运维直接重启了,也没日志,公司当时还有别的事要忙,就没继续改进。
#14 哇,大佬✨ nbio 在 windows 下能支持 iocp 吗?不过我看 issue 里都没人提耶,看来需求不大…… 我就是问问哈,不是要大佬做哈,给大佬跪一个先🧎♂️。
#26 windows 只为方便开发。。打死我也不会去支持 iocp 了,哈哈哈,太难搞了
能不能改是看你写的好不好的,而不是看你是不是名人的
自己觉得有意义就好
此话怎讲,请细说
我一直不太理解,为啥 go 要上 epoll ,原生的 goroutine 在绝大多数场景下都没有性能问题,性能要求高的话可以上 rpc connect 复用。 感觉是 java 转过去的人卷的。
> 可,评论区的一些评论我实在看不懂~
你可能还不知道吧,以前只是站着说话不腰疼,现在是躺着说话他也不腰疼呐
我想说楼主自己写着玩没问题,我也喜欢整天搓这类底层小玩具。
但是楼主为了推广自己的玩具,不惜妄顾事实,说出“一个 conn 一个 goroutine 导致利用率低”这种笑话,那就没必要说什么“评论实在看不懂”了。
退一万步讲,在超大流量的负载均衡需求下才会有这种对极限性能的追求,这固然很酷,但是大部分场景都不会根据 plain text 跑分来做选型,这并不是性能瓶颈。
https://www.techempower.com/benchmarks/#section=test&runid=f35979a9-4e5e-41db-9ba2-9790167667e9&test=plaintext
目的就是一个连接对应一个协程,从而避免写异步代码。话说哪些异步回调有什么用?其实很难在中间插入什么逻辑的
1. 海量连接不等于超大流量
2. 海量连接场景下使用标准网络库会耗费大量内存,goroutine 调度性能下降. 很明显,reactor 模式能节省 read_buffer_size * num_connections 的内存,以及海量 goroutine 的栈内存。
3. op 没放任何压测数据.
发现已经 star 过这个项目了,哈哈
在 Go 语言中,使用 epoll 实现一个最小化的 IO 库是一个具有挑战性的任务,但也是深入了解底层网络编程和系统调用的好机会。epoll 是 Linux 内核提供的一个高效的 I/O 事件通知机制,常用于处理大量并发连接。
首先,需要明确的是,Go 标准库中的 net
包已经封装了底层细节,提供了跨平台的网络编程接口。但如果你出于学习或特定需求,想直接使用 epoll,你可以通过 golang.org/x/sys/unix
包来访问 epoll 系统调用。
以下是一个基本步骤的概述:
-
导入必要的包:除了标准的
fmt
和os
包外,还需要golang.org/x/sys/unix
包来访问 epoll 相关的系统调用。 -
创建 epoll 实例:使用
unix.EpollCreate1(0)
创建一个新的 epoll 实例。 -
注册文件描述符:使用
unix.EpollCtl
将文件描述符(如 socket)添加到 epoll 实例中,并指定感兴趣的事件类型(如读、写、错误等)。 -
等待事件:使用
unix.EpollWait
等待并处理事件。 -
处理事件:根据返回的事件类型,对相应的文件描述符进行读写操作。
需要注意的是,直接使用 epoll 需要对系统调用有较深的理解,且代码将不具有跨平台性。因此,在生产环境中,除非有明确的性能需求或特定需求,否则推荐使用 Go 标准库中的 net
包。