@fucUup 网络框架这一层处理数据收发。rpc 请求的限制，你在 rpc 框架收发数据的层完全可以自己限制。
兄弟，分层的理念你可以再加深下理解，不同的层处理自己的事情，从内核到应用，或者网络协议栈不同的层，都是各自处理自己层内的事情，该留给更高层去处理的留给更高层去处理，否则就拿你 rpc 4M 的来举例，如果网络库这一层写死了限制 4 M，你在其基础之上实现的 rpc 框架舒服了，但是其他人在其基础之上实现的其他业务可能需要大于 4M，那怎么办？所以，下层在自己层内资源可控的前提下提供上层所需的扩展机制、接口，而不是下层直接做这些限制

@fucUup 兄弟，你上面问的是为什么你们谷狗用 ET 而我的用 LT，那我不给你讲原理和实现原因，该怎么回答你？难道因为你们某个项目用了 ET 所以就应该用 ET ？那我是不是可以回答因为 redis 用了 LT 所以用 LT ？

工程质量，谷狗项目用啥并不是工程质量的唯一标准。另外，这里说网络库，网络库跟 MapReduce 这两者本来就是处于基础设施的不同层次，网络仓库作为数据传输的基础设施，MapReduce 是在网络或者其他整合生产消费的数据层之上的层，更多的是需要对数据生产消费的整合和加工，跟网络库本身没有可比性

@fucUup 还有云风的 skynet，印象中也是 LT 的

@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 协程这个成本还是很可观的