发布个 golang 高性能异步网络框架 nbio，单击百万不是梦！

[lesismal]

项目地址

• https://github.com/lesismal/nbio

• 主要特点：高性能、事件驱动、易用易扩展、省协程省内存、节能环保

关于另一个框架

• https://github.com/lesismal/arpc

• arpc 包括但不限于 rpc，网络交互模式完善推送、游戏、IM 等业务也都可以使用。并且 arpc 与 nbio 也打通了，支持使用 nbio 作为网络层实现更大并发量的支持

设计与实现的一些基本思考和细节方案

1. 跨平台支持：*nix 用 epoll 、kqueue, windows 用的 std/net
2. epoll LT，单次读最大可配，避免饿死
3. epoll 没有使用 trigger 模式，因为较新版本的内核 epoll 相关系统调用以及其他并行流 close 都是安全的，trigger 模式的无锁对性能提升也是伪命题，额外的系统调用以及内核部分的锁仍然是开销，应用层有锁并且单个 Conn 竞争几乎可以忽略，所以 trigger 模式未必有优势
4. Write 是直接写，写失败才挂到 Conn 的队列，再添加写事件，可写、flush 后清理掉写事件，尽量减少了 epoll/kqueue 的系统调用
5. 支持 writev
6. 实现了 net.Conn，支持 DeadLine，并发安全，也方便业务层多个并行流随意操作
7. 连接的管理，*nix 直接是 fd 做数组下标对应 Conn
8. 读缓冲、应用层最大写缓冲都可配
9. 用于读取的内存分配可由应用层定制，方便业务层做更适合的定制，这个不同场景可以玩很多姿势，简单的 pool 未必是最优
10. Conn 提供 Hash 方法，方便业务层用于消息分发到指定协程进行处理，从而保证每个连接的消息处理有序
11. 单独的 heap timer，不使用 time.AfterFunc 节约协程
12. 支持管理标准库的 net.Conn，比如使用 net.Listener Accept 或者 net.Dial 得到 net.Conn 放到 nbio.Gopher 里管理读写
13. 最少依赖，除了 tls 作为扩展是需要依赖我的另一个仓库以及 go1.6，单纯作为异步框架，nbio 只依赖标准库
14. server-side/client-side 都支持

• 可定制、扩展的挺多的，不一一列举

与其他一些 golang 异步网络框架对比

1. 性能：我这里同样配置、参数压测，nbio qps 基本最高，多个框架的 pprof 分析，nbio 的 syscall read/write 占比应该是最高的，进入到 syscall 后的部分是框架层没法再优化的，这说明同一段时间内，nbio 更多的时间是在执行系统调用进行读写、框架本身的消耗占比小于其他框架
2. 易用性：nbio 实现了 net.Conn，更加业务友好、方便扩展定制，所以我最近花了几天把 go 1.6 std 的 crypto/tls copy 了一份，并重写支持了 nbio 的 tls server-side 、server-side，标准哭 tls 的读写 buffer 有点浪费，还有不少优化空间，但是暂时够用、不着急进一步魔改优化。

• 后续还考虑标准库的 http 是否也魔改一下支持异步，但是如果要改，工程量有点大，也是得慢慢搞了

一些例子

1. 使用 nbio 管理标准库 net.Conn

• std-net-echo-server
• std-net-echo-client

2. Echo

• echo-server
• echo-client

3. TLS Examples

• tls-server
• tls-client

更多示例请参考文档和代码

欢迎关注

• 欢迎 issue / pr / fork , star 更好

[lesismal]

@shujun 感谢支持！

[dubdub]

> 用于读取的内存分配可由应用层定制，方便业务层做更适合的定制，这个不同场景可以玩很多姿势，简单的 pool 未必是最优
请教一下大佬还有什么其他姿势呢

[lesismal]

@dubdub 比如标准库 tls 或者其他一些地方，或者 fasthttp 里，用到 2^N size 对齐的多级 pool ，nbio 里用的不是固定 size 的，go 的 gc 无法确定内存的精确释放时机，如果需要比较精准控制，甚至可以 cgo 直接调用 malloc 这些，得看实际需要了。

[kingcanfish]

虽然我不知道争论谁有道理 但是看帖子能学到很多知识（学生狗如是说