@trzzzz 是指定时器的 duration 会加上 10% 抖动的做法吗？

在补 Better Call Saul 风骚律师，到第五季拉罗登场了
比 Breaking Bad 更让人沉迷

@Flourite 嗯嗯，我觉得其实不少点在后续诸位老板的讨论输出的知识内容里已经比较清晰了（虽然有不少价值判断与情绪输出 hhh ），这样读到的人在了解之后对于这些编程语言都会有自己恰当的判断。

此外这套方案是通过牺牲数据完整性来提高性能的，因为这里很明显会有一批热数据还在内存里没写到磁盘的，所以如果发生断电等事故（程序没有优雅关闭）势必会有一些数据丢失，如果要保证数据完整性就需要引入 WAL 日志机制以及频繁的 fsync 同步写入来保证数据落盘，这个会非常影响性能，所以看自己权衡了，但 IoT 场景应该还好要求不高？

这里说个不用轮子如果自己实现的思路，可以参考 vmagent 的设计：

https://jiekun.dev/posts/vmagent-data-structures/

程序内部自己维护一个内存的数据队列（在 Golang 就是 Channel ），一批接收请求塞到队列里的 handler （ cpu num 个 goroutine ），以及消费内存队列数据块的 consumer

请求会以 round-robin 的形式分到这些 handler 里，handler 需要把接收到的请求里的数据组装成合适大小的 block （可能是几十兆？这个是调优参数），然后当 block 足够大或者每隔一定时间后，handler 就把 block 刷到内存队列里

塞进队列之前，会有一批 worker （应该也是 cpu num 个）会序列化（ protobuf 或者自己定义的二进制协议）并基于 snappy 或者 zstd 算法压缩这批数据 block ，压缩的关键在于大大减小原始负载的数据大小，进一步增加后续磁盘写入 IO 的吞吐

consumer 会将内存队列里的 block 拿出来顺序写入到本地文件中，多个数据条目拼装的 block 且经过压缩，落盘的吞吐还是比较理想的。

你需求的数据量其实也就每秒 2M 左右，如果压缩一下甚至这个数据量会更小，所以理想情况下应该比较低配的机器就能够满足你的要求。

核心就是组装（其实就是 buffer 的思路）和压缩，来尽量提高顺序 IO 的写入吞吐，这是容易产生的瓶颈。

当然这套方案只考虑了写入，在查询上是没有什么优化的（没有索引），所以如果要实现比较好的查询的话可能还是要考虑开源的轮子，基于 MergeTree 的 Clickhouse 以及 VictoriaMetrics ，或者 InfluxDB 等时序数据库方案应该能很好满足这方面需求，但思路还是要注意写入数据库时数据的合并来实现对于 IO 吞吐的友好

@lesismal #11

> 通常的定时功能没必要加抖动, 这个库的具体内容我没看. 定时加抖动有可能是为了避免同时创建大量具有相同超时时间的内容, 后续同时到期去创建大量协程异步删除内容导致 goroutine 过多造成不稳定, 或者其他什么特殊的需要

应该是这样，像 Kubernetes 项目里也会用到很多 Jitter 去避免相同的超时时间（ https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apimachinery/pkg/util/wait/backoff.go#L203 ），像 kubelet ， 以及几个组件的 LeaderElection 都会用到，确实还蛮常见的。

fastcache 也是分片锁的思路，切成 512 个 buckets ，进一步最主要就是针对 GC 做了优化，索引用 map[int]int noscan 来减小 GC 扫描开销，实际 key,value 放在一个自己手动 mmap 分配管理的 chunks （[][]bytes ）里，跳过了 golang 自己的堆 gc 。这套思路上生产很多场景应该是够用了

@lesismal 所以一般定时要求不严格的话很多 Golang 开源项目会给定时 duration 加个 10% 左右的随机抖动吧
例如 VictoriaMetrics 的 timeutil.AddJitterToDuration - https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/lib/timeutil/timeutil.go

我觉得不一定是拉踩，针对 Golang 的这一情况可以添加更多的说明会好一些。

如 @lesismal 老板所说，这里 golang 的开销应该是有栈协程的开销，一个 goroutine 栈默认最小是 2K ，1000,000 * 2K / 1024 / 1024 = 1.9G ，算上 sudog 等其他的结构加起来可能差不多吧。

实际 golang 处理异步任务的时候确实不会开这么多协程，更多是把协程池化然后基于 channel 通信来处理。

在实际 Golang 开发过程中确实会有每个 conn 对应一个 goroutine 大量连接导致内存过高的 case ，然后社区里确实有对应魔改 netpoll 以及 nbio 这样的方案来解决类似的问题。

@duebasser 主要我觉得作为闭源商业方案其性能与稳定性问题不想着如何解决，反倒变成了绑架与讹诈客户的工具，还是挺逆天的。

之前达梦的 .Net 驱动有很严重的问题，驱动执行一些 Insert SQL 失败会吞掉偶发异常，导致上层代码对于数据丢失不可知。

甲方对于达梦数据库的性能以及稳定性意见非常大，PG 32 核 64 G 的配置可以跑很稳妥的数据量到达梦这里好几倍的配置也经常崩溃以及丢数据，达梦那边给的回复是需要上集群版，张嘴报价几百 w…反过来绑架客户了

后面要求研发侧对于项目上国产数据库方案首推用人大金仓（好歹基于 PG ）了，如果有甲方要求用达梦会郑重劝告（ x

完成度很高👍

@qiuhang 其实我也猜测是这样，团队里没有专业一些的工程师。
但类似的专业度不足的问题过去几年已经出现过好几次了（ helang 、掰天线……），公司应该是盈利的，他的人脉哪怕只是找个顾问把个关应该也不难（不找其他 up 主，找个大厂上班的老同学或者学长之类也成吧），到现在还没解决这个问题只能说 emmm……

主要还是营销技术宅人设带来的反噬。

何的早期视频看出来属于是一个有自己创意的数码爱好者（果粉？）。但应该是 5G 视频之后为了接住这泼天的流量，何开始往“技术宅”人设开始转型，然而问题在于和手工耿、稚晖君不同，他自身的专业水平是不足以支撑这个人设的。

如果何同学团队具有一般软件工程师的专业知识储备，就会知道：
1. ascii generator 本身很简单，就算是自己写的也没啥了不起的，没必要抄别人的项目
2. 如果基于别人的开源项目实现也 OK ，但要遵循别人项目的开源协议，哪怕是非常宽松的 MIT
3. 哪怕再恶劣些，我抄了别人的项目说是我做的，但只要我视频里没有证据也不会有什么舆情，因为还是那句话 ascii generator 很简单，自己会写也不奇怪。

最烂的情况就是现在：我拿了别人项目声明是自己写的，然后把证据放到视频里还不自知。

之前看过何同学关于自己在互联网舆情的访谈，我觉得多少是可以理解的，但我也确实没想到 2024 年快结束了他们团队还会犯这种基础的专业性错误，确实有点自业自得了。

主要就是 @CLMan 老板提到的接口类型约定的是方法调用，所以大部分场景不需要检查接口的值是否为 nil ，要检查通过类型断言或者方法内部来检查。

Go 的语法细节确实有很多实际运行起来不符合直觉的地方，很多时候一定要结合它的内部机制甚至看源码才能顺畅理解， 虽然这些机制大部分理解了也确实比较简单吧（所谓“大道至简”…

感觉控制协程数量的场景属于内部造轮子可以解决的轻量需求，如果是我的话大概率也是自己造轮子来定制（参考开源实现）而不是引入第三方依赖。

发现自己贴错了 issue： https://github.com/golang/go/issues/64825 （ x
这个讨论还提到一个点，就是常量，现在常量由于这个类型转换的限制可能对于同个常量会写两个类型（ bool/int ），这在 Go 编译器和运行时的代码里就有出现（ src/internal/goexperiment/exp_arenas_on.go ）：

const Arenas = true
const ArenasInt = 1

总之这事目前来看没有明确拒绝的理由，更接近于懒得搞，如果有人愿意费力气把这变更做了，感觉 Go 团队这边也会接受。

（其实这种类似的情况在 Go 社区有很多，习惯就好）

我翻了下 Go 的 Github Issue ，其实有非常多人的提过这个 int(bool) proposal 。
包括今年也有关于这个的讨论： https://github.com/golang/go/issues/6011

看得出来不少 Go 团队的成员是支持加入这个特性的，主要反对的人是 rsc ，他认为这个变更工作量很大，同时觉得收益不高，Go 团队时间有限，要搞的话你们自己搞：1. spec 的变更； 2. 编译器和 go/types 的变更； 3. 把 Go 主仓库相关代码更新了以尽可能用上这个新特性，来证明这个特性对于 Go 而言是有用的。

所以感觉更接近 Go 早期版本忽视了这个特性，然后现在随着 Go 发展要加进这个特性工作量大了就懒得搞了。