lesismal

lesismal

V2EX 第 497905 号会员,加入于 2020-07-06 13:49:58 +08:00
今日活跃度排名 12823
lesismal 最近回复了
5 天前
回复了 liu1996 创建的主题 程序员 关于 socket 的一些问题
楼主需要:《图解 tcp/ip 》+《 tcp/ip 详解》+ wireshark
1. 入门阶段,如果不看图解这本、直接啃详解或者其他数很吃力要花费很久;
2. 没有详解这本,图解又太简单了,了解不到深入细致;
3. 没有 wireshark ,看再多也难记得住,实践出真知。另外 tcp 是大头,把 tcp 11 种状态转换图放在桌面上,配合抓包看 tcp 各种流程,tcp 搞熟悉了其他的多看看就容易得多了
6 天前
回复了 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 的一些优化,请根据自己实际情况进行
看来这个帖子是我再次犯二了,不能奢望搬砖逻辑程序员级别的人去理解到稍微复杂一点的超过他们技术认知范围的东西,就像我听不懂更牛逼的程序员、科学家的日常一样。
我散了,节省点自己时间。
@buffzty 所以说,用过的人直呼内行!
> 接受一部分语义,然后说其他语义不安全,很难不笑出声。有这本事应该去把 GCP 、AWS 、Azure 、阿里云、腾讯云、百度云等大厂的 RESTful API 给黑了

我真是佩服你们这些人断章取义、拿出别人观点中的一部分词进行曲解的能力

之前的好几楼我已经都说过了,这时代电子产品多眼睛容易疲劳,视力不好建议多做做眼保健操
> 现在有点趋势上的包袱反而在前端,当年历史原因这套系统选择了 angular 作为底层框架,进新人特别慢,上手 angular 确实需要两周的时间,现在国内几乎是 vue 的天下

这确实了,前端历史包袱也重

> Websocket 这东西,一直没怎么用起来,看过有有人用 Websocket 写的 bbs 项目,各种原因也没推广开,没测过,但是有状态协议,对服务器的压力还是比无状态大的

有状态的协议,实现复杂度比 CURD 要难得多
性能压力未必更大,因为有的需求,如果用无状态只能轮询,轮询的压力更大,得按实际场景对比
另外就是,复杂些的需求,无状态真的搞不定,所以才会额外要搞 RPC 要搞各种自定义协议,这也是我不喜欢 HTTP 的原因之一
@pkoukk
我也没说过不能用啊,说几句不好,大家就都觉得我说不能用了 :joy:

看下 #178 和多几个楼的回复
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1159 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 19ms · UTC 23:57 · PVG 07:57 · LAX 15:57 · JFK 18:57
♥ Do have faith in what you're doing.