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

@buffzty 所以说，用过的人直呼内行！

> 接受一部分语义，然后说其他语义不安全，很难不笑出声。有这本事应该去把 GCP 、AWS 、Azure 、阿里云、腾讯云、百度云等大厂的 RESTful API 给黑了

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

之前的好几楼我已经都说过了，这时代电子产品多眼睛容易疲劳，视力不好建议多做做眼保健操

> 现在有点趋势上的包袱反而在前端，当年历史原因这套系统选择了 angular 作为底层框架，进新人特别慢，上手 angular 确实需要两周的时间，现在国内几乎是 vue 的天下

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

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

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

@pkoukk
我也没说过不能用啊，说几句不好，大家就都觉得我说不能用了 :joy:

看下 #178 和多几个楼的回复

@leeg810312
#88 #178
这些，你能看懂吗？知道我在说啥吗？能读懂我的观点、论据、对比说明吗？知道你自己在曲解、驴唇不对马嘴无论据口嗨吗？

> 你的回答是不是趋势不一定对，主流不一定好？看来你是权威，只有你才能决定什么是对，什么是好

#132 里我回复过你 “流行不代表就是主流，即使主流也不等价于最优”
看准了，“”主流也不等价于最优“，这句话你就推断出 “主流不一定好”，“好”跟“最优”是一码事吗？你了解除了 HTTP 之外的各种协议吗？知道其他各种领域各种场景各种协议为啥不直接用 HTTP 吗？知道 HTTP 这么 “牛逼” 为啥大家还要搞 RPC 还要搞 Websocket ，为啥其他不受浏览器限制的还要直接 tcp 自定义协议，还有很多为啥要 UDP ?
知道 HTTP 1.1 主要解决了啥吗？知道为啥还要继续搞 HTTP 2.0 、2.0 解决了啥吗？知道为啥 HTTP 2.0 还没普及就 HTTP 3.0 标准都基本达成一致了吗？知道 HTTP 3.0 为啥用 谷歌 QUIC 知道为啥要基于 UDP 吗？

你眼里的好，是因为你接触到的技术范围就局限在你熟悉的 HTTP 周边小范围内，并且你只是使用者，自己没做过这些基础设施没思考过当下所用之物有哪些缺点、不足、不能满足哪些需要、可以做哪些改进优化，所以你都不看我在对比什么。别跟个井底之蛙似的

#132 回复你的我再贴一次：
"所以这些楼层下来，相当于我在说 A 不如 B ，并且我解释为什么 A 不如 B ；然后你们就说你们在用 A ，你们给大厂的方案也是在用 A ，云厂也在用 A ，驴唇不对马嘴地怼我呢，多数都没怼到我聊的点上，也不提一些论据“

@leeg810312
我希望聊技术的人能带上点脑子，就比如 go 吹，go 吹就不能聊这些设计了吗？前面楼问过其他人，现在也问你一句：你逻辑及格了吗?

#132 回复你的你能看懂吗？
#178 的回复你也可以看一看

说自己十几年经验，一直在这断章取义、望文生义、无论据式无脑口嗨，十几年就这？十几年一直写 CURD 了是吧？只会为杠而杠是吧？

能看懂我回复再来 at 我行不？

@FakNoCNName 我真正在辩论的点可能大家好些人都没理解到，请参考我 #178 的回复。

> 旧的不一定过时，但总有一天会过时，新的不一定成为标准，但成为新标准的肯定是新技术。

>（技术方面聊到这里其实已经没多少可以争论的了，大家都说清了主张和原因，很多东西都是有历史原因的，也需要考虑成本，最后总有一方需要改变。）

这些我也是都认同的，前面几楼也解释了一些。因为好些位看到个关键字就断章取义了，把我意思都给曲解了 :joy:

@twl007
> 感觉你可以去跟 Box API 的团队讨论下 API 设计 人家 get put post 语义明确 用起来一点毛病没有
> 不知道 Box 算不算特定领域亦或是人家对安全要求低 反正没见人家有这个问题

我好像没说过所有 PUT/DELETE 不安全吧，包括转的帖，也是说特定场景下的不安全比如文件服务相关的，而比如前面其他人提到的云厂 API PUT ，以及你提到的 box google ，API 接口控制好，我也没说有安全问题，但这些都是控制好的前提下，我们不能指望所有团队都按照你提到的厂的规范，尤其这世上还存在很多健在的 php asp jsp 项目。

我之前有说，在这个帖子里关于 PUT 的观点包括几个方面：
1. 安全规避以及替代成本不高
2. 与其他方案对比的优劣
3. 工程、跨工种 /部门 /公司协作

我并没有说 REST 就一定不安全、不能用。但是 PUT 在现实场景里，就是有的人会面临 1 和 3 的额外的麻烦比如楼主的项目，而如果不用 PUT ，则可以免掉这个麻烦，而且抛开项目历史包袱，POST 替代 PUT 成本也可以忽略

REST 的各种 Method ，一是基于 HTTP 协议本身，二是基于社区发展实践和历史，按照工程实践形成的规范继续实践下去也 OK ，但是我说的是与其他方案对比的优劣，如我 #88 中说过的，各位没有考虑参照物对比、只是说 REST 可以用，各位跟我聊的甚至不是一个事情

#88 我已经解释了一些，各位有没有想一下，如果早期 HTTP 就没 Method ，大家还必须依赖 Method 吗？只用路由能搞定吗？ RPC 的 'Method' 其实是相当于 HTTP 的路由，RPC 其实没有 HTTP 这种在路由之外额外再套上的 Method 区分，即使 GCP 文档里的 PB RPC Service 定义部分，也是直接把 HTTP Method 映射到 RPC Method 上（就是方法 /函数名），相当于我 #88 说的 路由+参数 两个维度，并不需要三个维度。其他的很多自定义二进制协议场景也是类似，路由 /方法名 /命令号 + 参数 这两个点就足够了，也是并不需要非得搞成三个维度

我真正想聊的，是自底向上从不同的设计方案来对比 A 和 B 两种方案或者设计 /使用方式，哪种更简化、更省更好，而不是各位这种多是自顶向下从如何使用 A 或者在 A 的历史实践中形成的经验如何好用。

所以跟 box 聊设计或者跟 google 文档对比，跟我说的这些都没什么关系，希望有人能 get 到我说的点，而不是继续跟我聊 A 方案为什么好用。

@TossPig @iseki
刚洗完澡头发还没干，所以又来补一波。。。

其实相比于 RESTFull ，post+struct body 方式的路由也好、参数也好（甚至路由也放到 body struct 字段里，但是比如 nginx 日志之类的不友好、需要插件解码再日志才行），更统一，比如参数，不需要再去 header 的 kv 、form 或者 body 各种地方取，而且写法上，以 go 语言为例，一个 ctx.Bind(&args)，后续的参数就都可以是结构体字段，干净得很。有的人喜欢省事用 map 类型，然后取到 interface{}再解析，这种不推荐，理由跟强弱类型语言做工程的优劣类似，而且项目足够规范，就应该协议制定阶段定好类型，然后就都很规范干净。当然，不同语言，强类型、弱类型、还有 java 这种带注解的，对于这种方式参数使用的便利未必一样。但至少在 go 和其他一些语言领域，或者从设计、获取参数来源上，确实是简便了一些的。而且 RESTFull 多种方法相关的，我前面说路由命名一样能解决，RPC 也一样的道理，如果命名解决不了，那 RESTFul 也未必能解决的了、只是增加一个维度的复杂度而已。

一些传统业务，社区已经既有很多成熟的解决方案，比如企业级、电商、管理后台系列、金融相关的很多，还有一些语言优势领域比如 PHP ROR 各种擅长的中小项目领域，这些成型的成熟方案改造使用 post+struct body 没什么必要，或者像楼主这种，公司已经形成了比较统一的项目规范，改个另类出来反倒增加团队负担，也没必要。
但是近年的一些新项目，尤其 go 语言这种，因为没有历史包袱，主流的框架以及相对中等以上水平的团队，很多都会选择 post+struct body 的方式。所以之前其他楼一些同学说我应该跟上时代，我都觉得他们有点说反了，可能他们才是没跟上时代吧 :joy:

另外关于 websocket ，我这有个 go 的 rpc 框架，支持 websocket 作为 transport 层，而且不只是 rpc ，可以服务端主动发消息给客户端，可以避免线头阻塞，可以乱序响应，而且能够支持更多业务场景比如推送、IM 、游戏等等：
github.com/lesismal/arpc

go 的 rpc 框架里，性能我不敢吹第一，但哪个框架说它第一的话我也不服。。。这有一份相对客观公正的 go rpc benchmark：
github.com/micro-svc/go-rpc-framework-benchmark

这里有个 websocket 聊天的简单例子：
github.com/lesismal/arpc/tree/master/examples/webchat

如果各位有兴趣玩 go ，欢迎多多交流

辛苦攒的 v 币，今天消耗了太多，怀疑一些层主上来就口嗨是过来骗我 v 币的，真是坏得很呢。
这个帖子不想再扯了，睡觉了，晚安各位。

@iseki 嗯嗯，能保系统是第一位的，其他的慢慢演进吧，每个团队每个人都有自己的设计审美，而且是否流行与是否主流与是否优雅也通常不是绝对正相关的，大家能赚钱、能有朝一日全民不卷就好。

@xfriday 是的呀，怎么了，我也是被你们各位上来就口嗨给逼的呀，只能这种戏谑点方式和心态防止自己被气坏啊，所以请多理解，而且对认真聊技术的人我可是没这样说话的呀。。

@skinny @hack

我在这个帖子里对于 PUT 的观点包括几个方面：
1. 安全规避以及替代成本不高
2. 与其他方案对比的优劣
3. 工程、跨工种 /部门 /公司协作

前面回复的太多了，这会也快睡觉的时间了，就不挨个楼去整理了

我前面还说过好些人断章取义，望文生义、无论据式口嗨、看都没看懂上来就怼，你们对待技术真是够随便的，我得庆幸还有很多不随便的人。