lesismal

lesismal

V2EX 第 497905 号会员,加入于 2020-07-06 13:49:58 +08:00
今日活跃度排名 13012
lesismal 最近回复了
都成年了,心态还是个小学生,先把 “家长” 这个词换成 “父母” 再考虑搬出去吧
连接数不等于 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 也好,有兴趣的同学,建议自己跑代码亲测对比,而不是只看别人仓库文档里的数据,因为一些朋友交流下来,自测结果跟一些公司出品项目自带文档里的排名数据对不上,这其中可能有环境差异的因素,也可能有一些其他因素,但请以自测为准。
2 天前
回复了 llys 创建的主题 PHP PHP8.1 发布了,好像大家都不太关注呢
它的时代已经过去,请让它自然死亡,仅以墓志铭纪念它曾经的辉煌:
“PHP 曾经是世界上最好的语言,Let it Go!”

请注意,"Let it Go" 双关!
3 天前
回复了 daoqiongsi1101 创建的主题 Redis Redis 大 key 自动过期的问题
4.0+ unlink 也可以,但是 unlink redis 线程之间通知之类的会多消耗一点,如果你们业务量大对 redis 的请求很频繁,用业务服务分批删、能替 redis 节省点性能可能对整个集群更划算,根据你们实际业务来判断
3 天前
回复了 daoqiongsi1101 创建的主题 Redis Redis 大 key 自动过期的问题
元素数量多,实现上是 map+skiplist ,因为非数组结构(非连续内存),所以没法像操作单个元素那样删除所有元素,而是需要遍历删除每个节点,元素多,一个 op 整体删除肯定要阻塞其他请求较长时间。

你可以分批删除,比如 zremrangebyrank 一次删除 N 个,多次之间间隔 sleep 下(或者单次 op RTT 本来就有网络往返时间,一般不 sleep 也可以,看你们主业务的需要),因为是要删除的数据,删除慢点应该也无所谓,N 和是否需要 sleep 自己把握就行
3 天前
回复了 EscYezi 创建的主题 JetBrains JetBrains 对标 vscode 的产品来了?
对标 vscode 的重点应该是免费吧
11 天前
回复了 liu1996 创建的主题 程序员 关于 socket 的一些问题
楼主需要:《图解 tcp/ip 》+《 tcp/ip 详解》+ wireshark
1. 入门阶段,如果不看图解这本、直接啃详解或者其他数很吃力要花费很久;
2. 没有详解这本,图解又太简单了,了解不到深入细致;
3. 没有 wireshark ,看再多也难记得住,实践出真知。另外 tcp 是大头,把 tcp 11 种状态转换图放在桌面上,配合抓包看 tcp 各种流程,tcp 搞熟悉了其他的多看看就容易得多了
12 天前
回复了 firejoke 创建的主题 Python 关于 asyncio 执行 IO 密集型操作的不解
不是说给函数加上异步就是一切都异步了:
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 的一些优化,请根据自己实际情况进行
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3843 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 08:00 · PVG 16:00 · LAX 00:00 · JFK 03:00
♥ Do have faith in what you're doing.