@hellodiu http2 太垃圾了，文件服务 4 层线头阻塞表现不如 1x ，动态协议交互 websocket 也比它好用，谷歌非要用 http2 做 grpc 网络层也是醉了。而且使用 grpc 的场景基本上连接数量不会太大，标准库性能更友好，而且这又是需要一大波体力，所以暂时没有支持它们的计划

完善了两个仓库

golang 性能最好、易用性最强、支持的业务场景最多的 RPC 框架
https://github.com/lesismal/arpc

golang 性能最好、易用性最好、目前全网唯一支持 tls/http1.x/ws 的 poller 框架
https://github.com/lesismal/nbio

妹妹你老公是真不行

socket 四元组是指协议层面的

对于程序，你可以当成是五元组: 四元组 + fd （ accept/connect 返回的文件描述符）

@lesismal
#8 更正，四元组的概念是基于 4 层协议，4 层协议 port 是两字节，久了记忆和知识点越来越模糊了，随口说容易犯错

@openp2p 自己仓库能有朋友认可是我最大的荣耀，没有什么能比这更让我开心的了，哈哈哈，感谢支持！
openp2p 已 star 收藏，得闲了我也来学习使用下

碧马温

都成年了，心态还是个小学生，先把 “家长” 这个词换成 “父母” 再考虑搬出去吧

连接数不等于 qps ，如果百万连接数建立起来放那不用，也没什么压力呀，所以你看石墨的文章里，好像只是 5s 广播一次不算太大的消息吧，48w/5s ，不到 10w qps ，这个确实没什么压力，对于很多语言都没压力

基于以上，楼主缺少正常的压力数据指标来对比性能是没什么意义的

另外，
“然后我在 v2 搜了一下，好家伙，有人宣称自己写出了单机 100w 连接数的网络库。一看也是 go 。”
这好像是在说我？但是宣称这个词感觉怪怪的
我这也备上了 websocket 百万连接的测试例子，有兴趣的同学完全可以自己跑下试试、而不是觉得这只是宣称，因为这应该是事实：
https://github.com/lesismal/nbio-examples/tree/master/websocket_1m

老帖子在这：
https://www.v2ex.com/t/763906
https://www.v2ex.com/t/794435


鸟窝老师还有篇帖子对比 RPC 框架的，我的另一个仓库也在里面
https://colobu.com/2021/08/01/benchmark-of-rpc-frameworks/

百万连接也好、RPC 也好，有兴趣的同学，建议自己跑代码亲测对比，而不是只看别人仓库文档里的数据，因为一些朋友交流下来，自测结果跟一些公司出品项目自带文档里的排名数据对不上，这其中可能有环境差异的因素，也可能有一些其他因素，但请以自测为准。

它的时代已经过去，请让它自然死亡，仅以墓志铭纪念它曾经的辉煌：
“PHP 曾经是世界上最好的语言，Let it Go!”

请注意，"Let it Go" 双关！

4.0+ unlink 也可以，但是 unlink redis 线程之间通知之类的会多消耗一点，如果你们业务量大对 redis 的请求很频繁，用业务服务分批删、能替 redis 节省点性能可能对整个集群更划算，根据你们实际业务来判断

元素数量多，实现上是 map+skiplist ，因为非数组结构（非连续内存），所以没法像操作单个元素那样删除所有元素，而是需要遍历删除每个节点，元素多，一个 op 整体删除肯定要阻塞其他请求较长时间。

你可以分批删除，比如 zremrangebyrank 一次删除 N 个，多次之间间隔 sleep 下（或者单次 op RTT 本来就有网络往返时间，一般不 sleep 也可以，看你们主业务的需要），因为是要删除的数据，删除慢点应该也无所谓，N 和是否需要 sleep 自己把握就行

对标 vscode 的重点应该是免费吧

@buffzty 感谢支持！有好玩互相喊一声

楼主需要：《图解 tcp/ip 》+《 tcp/ip 详解》+ wireshark
1. 入门阶段，如果不看图解这本、直接啃详解或者其他数很吃力要花费很久；
2. 没有详解这本，图解又太简单了，了解不到深入细致；
3. 没有 wireshark ，看再多也难记得住，实践出真知。另外 tcp 是大头，把 tcp 11 种状态转换图放在桌面上，配合抓包看 tcp 各种流程，tcp 搞熟悉了其他的多看看就容易得多了

不是说给函数加上异步就是一切都异步了：
1. 异步的函数 A
2. A 内部调用 B C D ，B C D 有任意同步阻塞的行为，A 也一样跟着阻塞

py 的性能痛点远不只是 asyncio 就能解决的了的，how about trying golang -_-

### 选型
因为楼主希望不要用 mysql ，所以选择 mongodb ，能支持的数据量足够大，并且 nosql 方便扩展

### 信件存储方案（按类型分别处理，广播类信件去重）
1. 系统发给用户，多个用户收到的是相同内容：只插入一条到 letter 集合中
2. 系统发给用户，多个用户收到的是不同内容：一个用户一条插入到 letter 集合中，类似用户发给用户
3. 用户发给用户：每个一条插入到 letter 集合中

### mongodb 集合（ collection ）和 文档（ document ）设计
mongodb 的 collection 相当于 mysql 的 table
collection 里的 document 相当于 table 的一条数据 collection 设计：
1. collection name: letter
document struct:
{
"_id": xxx, //mongodb 自带的就行
typ: system/p2p/...,
time: xxx,
from: userid:name, //用户之间的会有这个字段，系统发的看功能设计是否需要
content: xxx,
...
}

2. collection name: letter_list
document struct：
{
userid: xxx,
letters: [
{
id: letter_id_xxx, // 根据信件 id 去 letter 里查
time: xxx,
readed: 0,
},
......
],
}

优化：上面的 1 、2 中的 document 是为了方便展示，直接是用展开的结构字段，实际使用中，应该把各个字段合并编码、减少字段数量、从而减少相应的计算消耗和存储空间占用等成本，比如冒号分隔符分割多个字段，取出后 splitN 得到各个字段内容
letter 可以优化成：
{
"_id": xxx, //mongodb 自带的就行
info: "type:time:from:content", // 例如： "0:1637396101::您的超级 VIP 已经开通！"， "1:1637396101:用户 B:您的回复太棒了，非常感谢！"
// content 应该放在最后，以面 content 中有冒号时放在中间 splitN 无法正常解析
}

letter_list 可以优化成：
{
"_id": xxx, //mongodb 自带的就行
info: "id:time:readed", // 如："aaaa:1637396101:0"
}

### 其他
具体细节以及 mongo 的一些优化，请根据自己实际情况进行

看来这个帖子是我再次犯二了，不能奢望搬砖逻辑程序员级别的人去理解到稍微复杂一点的超过他们技术认知范围的东西，就像我听不懂更牛逼的程序员、科学家的日常一样。
我散了，节省点自己时间。

@fregie
看了下，如果是给个人用户，太重了，没必要，感觉更适合做机场。
对这个兴趣不大，祝顺利！