@fucUup 目前没有测试表明 ET 更快，实际上只作为网络库压测的情况，ET 和 LT 能达到基本相同的吞吐量，很多选择 ET 的可能是出于对 epoll_ctl 说明以及对 LT 用法不当导致的误解：
https://man7.org/linux/man-pages/man7/epoll.7.html

When used as an edge-triggered interface, for performance
reasons, it is possible to add the file descriptor inside the
epoll interface (EPOLL_CTL_ADD) once by specifying
(EPOLLIN|EPOLLOUT). This allows you to avoid continuously
switching between EPOLLIN and EPOLLOUT calling epoll_ctl(2) with
EPOLL_CTL_MOD.

但实际上 LT 也可以避免不必要的 syscall，可以参考 nbio 的实现

ET 和 LT 各有利弊，比如 ET，需要谨慎处理读写、避免 bug 导致 hang up，而 LT 处理逻辑更简单（ nbio 的方式，其实可能比 ET 更省 syscall，因为不需要每次读完再去重新 epoll_ctl ）

ET 要求单次 event loop 读完单个 fd 的所有，但其实，如果这单个 fd 上面数据非常大，比如多个应用层协议，反倒可能造成这单次 loop 内处理它耗时长、其他 fd 的等待，而 LT 单次 event loop 内单个 fd 可以不全读完，可以控制数量避免其他 fd 等待太久，反而能更公平

另外，redis 是用的默认 LT，muduo 陈老板也是默认 LT
nginx 年代较早，man 手册的建议以及 ET 也并不比 LT 性能差，所以即使 LT 实现逻辑更 easy 也没必要改

@wslzy007 不要用不一样的东西进行对比。nbio 目前只是网络库，不是 http 框架，所以没有意义。
另外，性能对比涉及很多方面，连接数、并发请求频率、payload 、应用层框架功能完整度、针对性优化等，每个点的差别都能带来较大的性能差异。

golang 的异步网络库主要优势是面对大量连接数场景下，节约大量的协程数量，从而减少对应的巨大内存消耗和协程调度成本。当连接数较少时比如几百几千个连接数（系统硬件资源不同这个阈值不同），异步网络库不会有明显优势，但是连接数上升到数万甚至数十万、上百万时，标准库的绝大资源消耗和性能下降会非常明显

上一楼错别字：近年独角兽

不能编辑，这个真的有点难受

至于 netty，确实挺不错的，但是要真说强，咋都当 c/cpper 灭绝了？比性能都不带上他们，这太不讲武德了

另外，我无意挑起语言之争，只是个人审美，喜欢简洁，java 本身强于社区而非语言本身，但是性能也并不足够强，否则 google 当年引进 python 失败就不至于搞 go 了（ google 被 cpp 虐惨了，看 py 牛逼，想引进 py 解决工程问题，也正是那个时段，py 之父去了 google，但是后来 google 醒了，发现 py 的性能实在坑，所以又放弃了，但是没有选择 java，而是搞了 go，也正是 go 开始逐渐成型后，py 之父离开了 google，虽然 py 之父的来去未必都是直接联系，但也一定程度上是 google 内部技术升级的时代使然）

还是那句话，如果 java 真的足够好，天下一统，全都 java 不就完事了？为啥今年独角兽、明星企业大量搞 go 为啥 java 份额下降了？

但是，如果新手选技术路线，我还是建议 java，因为好岗位多、待遇好，赚钱第一嘛～

@byte10 如果觉得搞这种异步框架也没用，那是因为社区还没有足够多的支持 golang 异步网络库的业务层框架比如异步网络库之上的 web 框架
别着急，老夫抽空慢慢搞，或者其他哪位大神大仙，早晚会有人搞出来

@king888 请看我上一楼回复的测试数据，有兴趣的话可以尝试下测试代码的链接。不是做 http 测试，因为暂时没有支持异步框架的完整功能的纯 go http parser，我打算闲余时间愚公移山搞一套
nbio 或者其他的 golang 异步框架，正是为了解决类似这种 13G 的问题

@byte10 linux 下 nbio 普通压测，客户端服务器共用单机 localhost 2w 连接数，2w 个 client echo 压测不停收发，payload 比较小只用了 64 字节，4c8t/4g 的虚拟机，ps -aux 查看内存占用 0.4%或者 20M 左右，qps 大概 25-30w，如果只是连接数较高、qps 不高，除了 nbio.Conn 的结构体按比例扩大下内存占用（估计百字节左右乘以个连接数），处理请求使用的内存也不会太大

测试代码在这里，有兴趣的话可以来试试：
https://github.com/lesismal/go_network_benchmark/blob/master/nbio/nbio.go

ps：linux 下每个 Conn 是挂到对应的 poller 上，poller 每次 loop 的协程执行读，所以这个 poller 上的所有 Conn 可以共用这个 readbuffer，读到一个处理一个，当然如果需要解析、粘包 save 下次继续解析之类的，内存占用会更高，但是由于没有使用标准库的协程模型，已经把协程的资源消耗降到最低了，否则单个协程，go 不同版本有 2k 、4k 、8k，不记得现在是不是 16k 了，反正百万连接，较新版本的 go 单单用于创建协程就已经 8G 甚至十几 G 了
但是 nbio 或者其他的异步框架，不存在协程消耗巨大内存的瓶颈

@guotie 慢慢来吧，有需要的朋友用就行。以后有时间了我再多写些其他的，毕竟绝大多数人的需要是业务框架，多谢老铁支持！

@lairdnote

既然回帖的各路大神画风都很自信了，我也就不谦虚了

老夫本人就是系统架构，老夫搞这些就是为了解决、优化这些问题

@byte10 兄弟，你可以先看下我 4 楼里说的场景，还可以自己稍微测一下 go 标准库的 net.Conn 对比 epoll 这类的内存占用情况以及连接数很多时候的情况比如至少 1w 连接起步、稍微配置好点的硬件来个 5w 起步的连接数（连接数少则协程数量少、异步框架相比 go runtime 没什么优势）
你实测到一些数据，还可以再看下系统编程类的书籍，并且最好也深入理解下 go 的并发模型，20 多年前互联网早期 server 的进程池线程池模型、异步 IO 、以及异步模型比如 C/C++、同步模型比如 erlang 、golang 这些的发展史
万变不离其宗的是系统层的资源的有限，不管语言层面提供何种模型，系统资源始终是那些，语言层的同步模型需要消耗的内存和调度的 CPU 成本，对应得到的同步模型的便利，这二者在中小业务量级的场景可以兼得，但是面对大业务量级会存在一些平衡点，协程数量多时，打破了平衡，就会显得浪费、吃力
与 CAP 类似，现实中也有很多其他事情类似，影响一件事情的多个因素，此消彼长，打破了平衡，就损失了整体的收益

看一下星爷的《功夫》，看一下那个理发师小哥，然后再想想高手该怎么定义，多读书

ps：我也不是什么少年，十几年经验、奔 40 的人了，日常做系统架构、底层框架基础设施，如果标准库性能足够且好用，我就不自己手撸这些了

msgpack 挺好的，数据量比 json 省一点，比 pb 多，但是方便，基本够用了

你们用啥语言，如果是 golang，欢迎尝试我这个

https://github.com/lesismal/arpc

@sujin190 兄弟，首先，等你遇到更大的业务量级，或者自己做些压测对比下不同方式下的各项资源占用，并且，不要按照做中小项目来思考，放飞一下自己，把眼光放到一个更上面的层次，去思考下更宏大的代码运行的世界，比如我上面 4 楼说的算是一个例子

@dorothyREN 十分想改，奈何 V 站似乎没有此功能，我找了好几次了 :joy: 。。。

@sujin190
兄弟，你这么说是对系统架构的理解有偏差了

基础设施异步不代表业务层也必须异步，比如：
网络层异步，收到数据、decode 后，把 message 丢给业务模块的协程池，业务模块的逻辑还是同步的，需要考虑的是协程池的 size 、避免因为协程池数量平静导致业务阻塞，协程池这个问题在其他基础设施也一样，比如 sql 、redis 的连接池，不够用了该排队等就排队等

golang 给我们了协程，我们不一定只能用协程的同步逻辑
同样道理，其他异步设施，也不是强制你上层必须异步
而是，多种姿势摆在这了，业务层同步还是异步逻辑，你可以自己设计

@byte10 兄弟，java 如果足够好，go 就不会诞生了。。。
go 的协程也不是万能灵药，对于中小项目确实没必要，对于大项目，nio 还是非常有必要的
想象一下，如果你手上大厂某些业务几百甚至几万台硬件，如果 nio，可以节省很多成本，单内存占用就可以省太多太多了
云服务越来越广，高并发相关设施用 go 协程这个成本还是很可观的

@byte10 兄弟，我已经不是少年了。。。本来没想自己撸一套，但是其他那几个，实在不好用

试试我的异步网络库:

https://github.com/lesismal/nbio

真热闹，我也补充一些吧

前面的各位都只是说到丢给 redis，但是单就 redis 也有击穿、穿透、雪崩各种说法，1s 几十万全丢给 redis，也只能说各位逮到个好玩意就往死里操，还是太暴力太浪费了

缓存和持久层其实都还是局部性原理的范畴，既然局部性原理，就再进一步，内存缓存，内存缓存这块跟 redis 放一块的话也有多种实现方式，比如：
1. 热点 key 的数据，定时或者发布订阅或者其他什么更新机制，服务节点 load 到自己的内存，请求来了直接返回自己内存缓存的
2. 同 key 访问加锁串行化，上一个请求回来后把结果带回来，其他等待锁的先检查是否有结果了，有了就直接拿结果、不落到 redis 了，相当于合并了到 redis 的请求。这个过程当然也可以结合或者改成内存缓存，比如内存的 1s 过期，内存没有、再 redis 、持久层之类的

高配点的机器，如果不是大 key 、value，几十万 qps 没啥压力，我自己的 i7 PC 测自己的 arpc 都能 40 多万 qps