自己薪资属于隐私，上家公司如果有薪资保密协议则更应保密，HR 问这个是不合法的，可以拒绝提供

如果她坚持要侵犯隐私，就继续面其他公司，顺带着反问一些问题看对方是否也能如实回答：“你的性生活频率是多少？每次大概多久？出水吗水多吗？”

锻炼身体最具价值

@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 的一些优化，请根据自己实际情况进行