最近犯闲，想再写点啥项目，有推荐的吗？

[lesismal]

去年写了两个库，今年有人用到，心血来潮肝了几个月做了更多优化和功能支持，同领域性能和支持的功能、场景以及易用性基本都高于其他库：
https://www.v2ex.com/t/794435

然后最近又有点无聊，想写点其他的，因为只有自己闲的时候写写：
1. 只想做小而美的东西，不想搞太复杂、需要很大代码量的，除非有其他小伙伴组团一起玩
2. 限于 golang ，其他语言也会几门，但体力有限，撸不动那么多

各位有推荐的吗？

[XTTX]

lib 类的不了解有啥好玩的。 我最近碰到这么一个问题，硬盘多了不知道东西存哪里了。 我想做一个本地的 MD5 file ledger, 扫描我的几个存储盘，归类，记录真实存储地址和备份情况。 我找了一下没有找到类似产品，有的话告诉我

[XTTX]

如果有什么好玩的项目，也求带一个。go react js tailwind 都能写一点。时间多。

[kksco]

感觉可以把写的网络库写个教程，原理啥的布道一下。我也想参与一下

[XTTX]

我对 ws 七窍通了 6 窍，我大概知道一个 ip 支持同时 65k 个 ws 。更多的我就不懂了，我非常想了解更多。贴主能指个路就棒棒了。

[xingyuc]

我想写个 twitter ，写着写着就不困了

[lesismal]

@XTTX #1 每个人备份需求不一样，这个得自己搞，查找的话本身挺简单的，小工具按条件遍历下目录就行了

[lesismal]

@kksco
网络协议涉及的知识稍微多一些，实现一个只处理收发的网络库本身涉及的东西其实不算多，熟悉和理解阻塞非阻塞同步异步这些，熟悉 epoll 基本就可以了，甚至从零开始熟悉，边搜资料边实现个简单的 epoll server ，把 et|lt 都试试，跑跑压测，几天就玩明白了，再不济，随便搜几个开源的 epoll server 代码读一读就好了，网络库的读写部分代码量不需要很多，很容易就搞懂了。

然后是需要一些周边的东西了，比如定时器、io 线程池、逻辑线程池，然后再搭配其他基础设施，传统 c/cpp/java netty 都是异步为主的这里是线程池，go 是协程池，有一定差别，因为有协程的亲和性也好、gc 也好、代码指令速度也好，相比 c/cpp 肯定要差一些，所以通常不像主流的 c/cpp 网络库那样逻辑单线程，所以就会有多逻辑并发流相关的设计。再然后就是 http/websocket 这种 7 层协议的支持。

还有内存相关的优化，c/cpp 可以用 tcmalloc/jemalloc 之类的内存池，go 自带 gc 但是在异步网络库场景可能会造成比标准库同步方案更浪费内存的情况，所以可能也需要结合业务自行设计 pool 来优化内存使用。
另外 go 缺少异步的 tls 库，我 copy 1.6 的标准库 tls 魔改支持了异步，并且把 tcp 层 Conn 读写与 tls 、http 、websocket 都打通了共用内存池，尽量减少了开销（某些极端场景也会消耗较大内存，但通常按照业务实际情况可控）。
过去的几个月里，tls+内存池优化消耗了我最多的时间，因为 tls 本身的复杂+异步流解析+内存的精确分配释放确实有点烧体力。

关注过一些国内大厂人的开源视频流服务器，但简单 review 了下代码，有的地方 map 的并发读写都没处理好，高并发时容易出现 panic 、整个进程挂掉，所以前阵子其实还想搞一下视频编解码多协议的支持来着，但估计了下，实在是消耗体力，还是先算了。

需要注意的一点是，nbio 这种异步网络库，连接数少的时候并不比标准库一个连接一个甚至两三个协程的方案有响应速度的优势，甚至是劣势。标准库占用更多内存，但响应性可能更好。只有在连接数较大、协程数量带来的内存、gc 、调度等开销达到临界点时，nbio 才会有明显优势、服务更稳定。因为异步解析以及消息处理要丢给逻辑协程发生调度、不如标准库同协程内那么亲和性友好。nbio 的能力是可控的协程数量，比如 1000k 连接数我可以控制在 100 、1000 或者 10000 个逻辑协程处理，不会因为连接数暴涨而协程数量爆炸导致明显的 STW 甚至 OOM 。

之前有打算整理一份详细的 nbio 的设计与实现，但是列了一些提纲后发现展开了说够写一本书了，想写好点的话弄本书，参考之前一些首次出书的作者的心路历程，这个工作量业余时间搞至少需要一两年，所以暂时放弃了，以后如果有体力再考虑。并且网络库相关的，市面上已经有不少书了，传统好书看 Stevens 的 tcp/ip 详解卷一，卷二和卷三就不用看了，纸上源码确实难啃而且有些老旧了，UNP 两卷，网络那卷应该算必读吧，进程间通信那卷也可以看看，至少对 uni*发展史和基础的 IPC 机制都能有些了解，而且 Stevens 的书都写的很好，读他的书就像在跟他交流一样，APUE 也是这样子的。
其他的一些书，linux 服务器、高性能相关的，陈硕老师傅有个 cpp 的 muduo 框架和书，我没怎么研究过，但扫了一眼书的目录还挺全面的，可以读读看

[lesismal]

@XTTX #4
> 一个 ip 支持同时 65k 个 ws

这个说法不准确。一个 ip+一个 listen port ，跟另一个 ip 最多可以 64k 个连接，这还要受到系统参数限制比如 net.ipv4.ip_local_port_range 。

四元组的概念是基于 3 层的 ip 协议，四元组包括：
A IP && A PORT - B IP && B PORT

ip 协议 port 字段是两字节，而 tcp server 通常是 listen 固定的 port ，相当于 A IP && A PORT 固定，对于另一个 IP ，相当于 B IP 也固定，所以只剩下 B PORT 范围可变，所以就受 port 字段类型的限制，2 字节，64k ，再加上内核参数的限制。

但是如果 tcp server 监听 n 个 port ，B IP 就可以跟 A IP 建立更多连接数：n * min(64k, 内核参数限制)。

所以很多人单机测百万连接数要搭建 docker 或者虚拟网络，我为了省事，直接开多个端口，免去搭建的麻烦了：
github.com/lesismal/nbio-examples/blob/master/websocket_1m/server/server.go#L68

[XTTX]

@lesismal 谢谢解答。如果我需要做 IM 相关的 app ，我怎么样深入了解这方面的知识？有没有教程或者书籍推荐？

[lesismal]

@XTTX #9

不同体量的 IM 项目架构差别很大，比如几种：
1. 上古时期的 web 实时聊天室，网站总在线量不大，随便起个名字进房间，主要是文字或者固定表情，并且单房间在线数一般不打，实现逻辑简单，需要踩坑性能的也就是广播时候可能会涉及广播风暴需要做点批次合并发送的优化
2. 目标在线量不大但是有更多功能的 IM ，比如企业内办公用的，除了文字和固定表情，常见的传文件、发自定义图功能也有，因为在线量不大，数据、文件存储层不涉及太多，也不需要太复杂的分层、路由设计，单体架构随便都能搞定
3. 海量在线，比如 QQ 这种，文字表情文件图片语音等各种功能，除了代码架构的分层设计、路由，还需 CDN 各种运维相关的工程部署，需要数据库、缓存、小文件存储各方面的横向扩容机制，需要多机房等各种

每种定位不一样，人力、资金成本和架构、开发周期也差别大，只能按实际的搞，但单纯从需要的技能点来讲，长连接协议交互这块都不算难，更多难点是工程、尺度上的设计。

开源的有一些也可以作为参考：
B 站毛大的：
github.com/Terry-Mao/goim
前微信大专家：
github.com/OpenIMSDK/Open-IM-Server

我只是看到过社区、公众号之类的推这些开源项目相关的信息收藏起来了，没有深入研究，所以没有了解他们具体的架构、能够支持的用户量级和业务场景，通常够用了，自家可以定制化。

IM 支持的消息，需要分类对待：
1. 文字 /表情，表情也是可以 id 指代的所以也相当于文字，nosql 系的数据库有好些，或者 tidb 或者自己设计可以方便横向扩容的存储层都可以
2. 图片音视频或者其他类型的各种文件，需要文件存储的基础设施，开源的也比较多，开源直接拿来用，这其中可能还涉及小文件存储，应该跟大文件区分开，文件元信息也是可以放到数据库里，头条的小文件存储元信息好像是放到 tidb 里的

如果目标在线量不大，那就简单得多了

如果有兴趣积累 IM 的技术，你可以尝试自己动手从零开始搞一个，我那个 arpc 能够作为 IM 的长连接协议交互基础设施，最简单的就房间文字聊天转发，很简单，这里有个例子：
https://github.com/lesismal/arpc/tree/master/examples/webchat

[XTTX]

@lesismal 感谢！我准备从 https://github.com/mattermost 研究起。

[lesismal]

@XTTX mattermost 很 slack ，我也先收藏个，谢谢！

[graetdk]

@XTTX
以及楼主

可以一起搞搞东西，我灵感太多而开发能力和时间都不足，害


[lesismal]

@graetdk 没看懂是要搞啥，笔记、点子之类的记录本？还是把你的一些点子开发成产品？

我也攒了不少点子，但都是商业相关的，我更爱技术一点，所以一直懒得动手 :dog:

[kksco]

远程桌面这种呢，感觉代码量会不会有点大。

[jiziya]

写点自己用的到的。我用随手记数据出问题了，没人处理，只好换记账软件，挑了半天选了钱迹，发现有需求不能满足，然后自己写了一个，就仿钱迹加上自己需要的功能就够用了。

[lesismal]

@kksco 这个领域我不熟悉 :joy:

[XTTX]

@graetdk 谢谢你的诚实。 这个年代，单纯的点子是最不值钱的。我原来是学金融出身，互联网创业瓶颈就是不会编程，现在就靠时间和耐力一点点抹平这瓶颈。 如果你以后要找人合作，千万别这么说，千万。。。

[graetdk]

@XTTX 不是，我自己也写代码，这是我做过并且输出过的： https://greatdk.com/1687.html ，https://greatdk.com/1341.html ，我是想法很多，多到我自己做不完的那种，可能跟其他「只缺一个程序员」还是有点区别的，我贴的图就是我搜集 idea 的一个笔记

[lance6716]

大佬有没有对 MySQL 复制协议库感兴趣，目前还有一些问题 😂

https://github.com/go-mysql-org/go-mysql#replication

[lesismal]

@lance6716 go-mysql 这个库我自己项目也有用到过一些，我主要精力不是数据库方向，暂时不知道我能对这个做些啥。
看了下 issue 列表，如果是 mysql 功能性的，这感觉有点需要补课

[XTTX]

@graetdk 你的那个字幕工具还活着吗？ 最近我在帮一个国外的前端大神开通 b 站账号。他需要那种能自动加字幕的服务

[graetdk]

@XTTX 活着，最近还更新了一下，上次更新是 2 年前（逃

[XTTX]

@graetdk 发给网址让我研究一下

[rj15295774336]

socket.io 协议实现

[lesismal]

@rj15295774336
socket.io 用的人太少了，而且 websocket 足够用了

[buffzty]

没事就学学汇编, cpu,linux net 那一块吧
有趣的东西别人几乎都写过了,网络方面的就代理 爬虫 web 框架之类的 只有找到一个别人没有做好的东西 去做好才有趣

[lesismal]

@buffzty 汇编多平台也是耗神，而且不是做外挂、安全之类的没什么必要再搞了，绝大多数服务也不需要汇编级的优化，偶尔需要也是看看汇编代码琢磨下高级语言本身的优化写法，所以也是不打算了，linux net 本来也算熟。我列的两个项目一个是能支持更全面业务场景的 rpc 框架，不像其他 rpc 框架那样只能局限于 rpc ，还可以做推送、IM 、游戏之类的；另一个项目是个异步网络库，相比于其他的 golang 异步网络库，性能不低于任一，并且支持 tls/http1.x/ws ，其他异步网络库除了 gev 支持简单的 ws ，都不支持这些。这两个项目都算是 golang 领域里别人没有做好的。代理爬虫 web 框架也都是遍地，我的异步网络库 nbio 还基本兼容了标准库，所以比如 gin/echo 之类的这些都能够使用 nbio 作为网络层，然后能够节省大量协程数量和内存开销并支持单机 1000k 这种、不会像基于标准库那样协程数量爆炸、内存爆炸、调度和 gc 成本高、STW 。
这两个库目前也算版本相对稳定了，所以想找点其他好玩的又不至于消耗太大精力的，实在无聊的时候就读读其他好项目的源码了

[fregie]

我有个在做的项目，不知道你有没有兴趣
目前是个 VPN 服务端管理平台（其实本质上不限于 VPN 类），是照着云原生的方向去做的
https://github.com/fregie/simple
最近几个月沉迷暗黑 2 重置版没更新了...

[lesismal]

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

[buffzty]

@lesismal nbio 我早就完整看完了,写得很好. 我写代码只兼容 linux-x64 这样可以节省时间. 找到有趣的东西可以一起开发

[lesismal]

@buffzty 感谢支持！有好玩互相喊一声

[unlimitedge]

考虑换工作吗各位？知乎北京招聘靠谱的 Golang 后端研发。不卷！

[foam]

@unlimitedge 支持全职远程吗🌝🌝

[unlimitedge]

@foam 不支持哦

[openp2p]

我们的商业产品上刚好用上你的 nbio ，性能杠杠的，内存只有 golang 自动 net 库的的 1/10 本想用 epoll 重复造轮子的。看了你旧帖子，那些说没用的，只是对于他的应用场景没用。适合的场景，比如高并发但业务逻辑很简单的（像推送消息推送业务），就非常适合 nbio 。国内太卷了，搞开源不容易。最后，有空花几分钟试下我的开源项目 openp2p [github dot com/openp2p-cn/openp2p]

[lesismal]

@openp2p 自己仓库能有朋友认可是我最大的荣耀，没有什么能比这更让我开心的了，哈哈哈，感谢支持！
openp2p 已 star 收藏，得闲了我也来学习使用下

[lesismal]

@lesismal
#8 更正，四元组的概念是基于 4 层协议，4 层协议 port 是两字节，久了记忆和知识点越来越模糊了，随口说容易犯错

[hellodiu]

@lesismal 大神继续给 nbio 支持更多协议吧，http2,grpc 之类的，大部分用户（像我:||）都想用现成的😂

[lesismal]

@hellodiu http2 太垃圾了，文件服务 4 层线头阻塞表现不如 1x ，动态协议交互 websocket 也比它好用，谷歌非要用 http2 做 grpc 网络层也是醉了。而且使用 grpc 的场景基本上连接数量不会太大，标准库性能更友好，而且这又是需要一大波体力，所以暂时没有支持它们的计划

[Nazz]

大佬出书了我来买一本

[lesismal]

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

[honkki]

@lesismal 大佬有博客之类的吗

[lesismal]

@honkki 没有呢，我比较懒，都是搜别人的博客看😂。。