旧闻：“逃犯为何偏偏在张学友演唱会上被抓？人脸识别在中国大爆发”

学友演唱会上的人脸识别违法不？

我没读过太多别人源码，更多时候我是自己写

既然多数说的是 CURD 岗，OP 这个题目，换成“揪着算法”也适用

我和一个好哥们以前面试别人，如果公司给对应的岗位的薪资上限是 N ，但是候选人期望薪资小于 N 、比如只有 0.8N ，那遇到基础好的，我俩通常都给 N ，并且会告诉候选人如果 HR 咬人、该怎么跟 SB HR battle
所以希望 OP 不要记恨所有问得深一点的面试官，只要记恨那些故意恶心人甚至它自己都搞不懂问题的王八蛋面试官就好了

好奇问一下，躺平如何保健

免费的律师，咱可是不太敢用的呀

> “后端重业务，前端重技术”

既然楼主这样认为，那么后端留给其他人确实更好些。

@dcsuibian 多年前的第一批，2023 报导而已

可以搜下几位专家的一些帖子看看，结合自己的数据类型定制+测试优化下就差不多了：
真实环境下大内存 Go 服务性能优化一例
曹大带我学 Go （ 11 ）—— 从 map 的 extra 字段谈起

如果是通用缓存基础设施，用已有的那几个就可以了。但通用缓存都是走了一道序列化的，如果追求性能，表现会差一些。
如果不是通用缓存则不需要序列化，性能可以最大化，但要根据具体业务结合 kv 类型定制去指针化了。

前端请求 api/rpc ，后端之间 rpc 都一套就能搞定搞定，自带了简单的 pub/sub 扩展，也方便

只做 api 的话，可以试试我这个，可以用 websocket ，也可以用 http：
https://github.com/lesismal/arpc/tree/master/examples/webchat

@Nazz 年纪大了马上要整不动了😂

@Nazz
对于异步写的问题，其实 gws 只对标 gorilla/websocket 的话就可以不考虑它，因为只是提供 ws 的基础库，gorilla/websocket 和 net.TCPConn 也同样需要用户自己去封装读写。
但是用户使用涉及广播时，应该建议用户自己注意写阻塞可能导致的问题。
而且读写个一个协程虽然并不复杂，但细节也并不那么简单，一致性、时序性、timeout 等细节，都需要仔细处理。而且我个人就遇到过 5+以上的朋友来让我帮忙 review 他们 ws 的代码，其中有些代码的封装，其实他们是知道写阻塞可能导致的问题的，所以他们封装了单独协程+chan 写的代码，但一些细节上仍然存在问题比如导致 panic 、状态不一致、timer 泄露甚至协程泄露等。

@Nazz

> 断开连接是自动的
> 以我多年 crud 的经验来看，似乎很少有人关心 write 是否返回了错误. 一般来说，在 write 之前业务逻辑都处理好了，或者开启了协程去处理错误，有错误关闭连接退出就好

不是能不能断开的问题，而是 WriteMessage 后及时性的问题。按 go 的习俗，应该是 if err != nil 就处理了，但是 WriteMessage 不返回 err ，如果这后面还有其他逻辑，就造成了后面逻辑代码的浪费，虽然整体可能不影响，但你提供 err 返回毕竟也没什么复杂度。标准库也好、其他 repo 也好大家都是这样，你这里的设计会显得不符合习惯。
而且其实这样做，相当于是基于标准库的同步 io 、能够顺序代码的情况下，糅杂进来了异步框架的回调机制。nbio 的 OnError 这些也是回调，但那是因为 io 和逻辑协程是在不同协程，为了避免用户再占用一个协程来处理，只能回调，并且 nbio 的 WriteMessage 这些也是提供 err 返回的，所以也还算符合 go 的习惯

> 使用 channel 异步写会增加一倍的常驻协程，我更倾向于广播的时候开启一小批临时协程
> async write 这块我还有个 idea ，可以维护一个全局的 WriteMessageQueue

这两种实际使用的前提都是：业务无所谓，卡了就卡了吧

但对于工程严谨性和高实时要求的业务而言，都无法允许你说的这两种策略，因为都解决不了我说的问题，只要你是在单个循环中处理多个 conn ，就都可能存在一些健康 conn 被某些网络不佳的 conn 造成卡顿的问题。
举个例子，RPG 游戏，地图上广播的消息非常多，如果某个玩家的连接卡了，其他人都跟着卡，这是不可接受的，否则游戏服务提供者上线用不了多久就可以解散项目了，除非项目本来也没人、本来挣不到钱。
其他的游戏类型，比如 FPS 、Moba 类、其他 PVP 的动作类，都是同样的无法忍受这种一人卡多人的问题的。
复杂的 APP 业务同样会存在类似的消息推送及时性需要。
既然是做通用框架，就不要投机取巧了。协程多了硬件不够用，你还可以加机器解决，但是业务卡了公司都可能直接倒闭的，这是不行的。技术方案该硬刚的地方需要硬刚，该加机器的时候就要加机器。

> 我就和基于 std net 的库比一比

nbio 是支持直接使用标注库 std net 、不使用 nbio 自己的 poller io 的，这里例子代码就是基于标准库的，另外也有描述多种 io 模式的特点、可以根据自家业务特性来 cover 不同场景：
https://github.com/lesismal/nbio/releases/tag/v1.3.5

@Nazz 这样似乎有个问题，就是执行 WriteMessage 的地方没有收到 err 、出错了不好处理后续流程、比如应该踢掉连接，OnError 里收到 err 却不知道 WriteMessage 的上下文

@liuxu
以前基于 fasthttp 的有个 github.com/dgrr/fastws ，好像有点拉跨。这个基于 gorilla 的改天我也看看

> gws 在 write 时非常直接，一个锁就发数据了，其他 2 个框架 write 前或多或少的用管道或锁处理了下别的状态情况，然后才一个锁发数据

不管是锁还是 chan ，只要不是发送队列而是直接 conn write ，就都需要注意广播业务存在 #14 的问题

@Nazz #11 很正常，for loop 处理单个慢、其他要等，我在其他帖子里说的跨协程的各种逃逸成本、亲和性差之类的，异步部分只有在连接数达到阈值才有优势，所以我自己的库以前只支持异步的时候性能就是干不过基于标准库的，无奈加上了多种 io 模式支持后、阻塞 io 的 conn 就能干过了。
基于 fasthttp 的 fastws 那个实现好像是个前几年的在校生搞的，性能和资源占用好像更拉跨，也可以对比下看看

@Trim21
我总结了下，使用 gobwas/ws 的项目大概需要几个“靠”：
1. 一靠运气好（公网速度稳定）
2. 二靠没人搞
3. 三靠业务小

手动狗头:dog:

@Trim21
对。
使用 grilla/websocket 或者其他多数基于标准库的 ws 库，如果有广播业务，也要注意不只是处理读要单独协程，处理写也要单独协程，否则单个 conn 的写可能阻塞，造成类似的 for loop 内其他 conn 等待的问题。
基于 OP 的库也需要注意同样的问题。melody 对 gorilla/websocket 的封装是单独的写协程，代码质量还不错，可以作为参考

所以，没有必要测试 gobwas/ws ，它还不适合用于商业项目