儿子明年要三岁了，明年我也要准备扮圣诞老人了。

问我的话，我其实一点也不关心别人是怎么活着的，只要不违背普世的价值观与道德，然后不影响到我都 OK 。
身边朋友不结婚的、丁克的、性取向不同的都大有人在，每个人选择自己觉得合适的生活方式就好，人与人看似是同个物种，差别之大和疯狂动物城里的动物其实也差不多了。
有这个时间，我会选择更关注自己的生活。

我个人一直觉得主观感受的时间流速和单位时间里接受信息的信息熵有很大关系。
年纪越大，工作、生活的很多事情对于自己来说就是重复的，并没有产生特别多新的信息量，所以感觉今年和往年也差不多，导致感觉时间流速很快。
如果每天有足够的变化，可能你觉得这一年的时间就不会这么快了

感觉我确实答非所问了（ x
不过要找一个**真正没有使用依赖注入模式**的 Go 复杂项目感觉还挺难的

就我所知绝大部分 Golang 开发的偏基础设施与中间件的大型项目（ Kubernetes 、VictoriaMetrics……），以及包括 Go 语言 Runtime/Compiler 本身都没有使用 DI 框架。

所有的依赖都是自己手动处理的，通过一系列的 NewXXX 函数以及工厂方法。很多 struct 可能就是全局的，在 go 启动时候就创建起来，然后在 package 范围内可见。在一些场景里可能会用一个比较大的叫做 "xxxCtx" 的上下文 struct （注意这个只是 struct 起了个名字，而与 context 标准库无关），用来维护传进来的 dependencies ，供这个上下文的方法使用，对于内部的 struct 有点像一个 DI 容器吧，但这个 "DI 容器"的依赖本质还是自己维护的。

个人觉得手动管理依赖并不是邪恶的，Go 的隐式接口实现可以做到不少代码较好的解耦（虽然隐式接口实现有单独的槽点），Go 项目里这些 struct 的设计也大部分实现了依赖注入模式（构造函数注入、方法注入），足以支撑复杂的项目。

然后 Go 项目很少使用 DI 框架，这样大型项目手动维护一个 "Unit" 几十上百个依赖是不是太麻烦了？事实在于，Golang 这些项目的开发者不少都认为一个"Unit" 不应该和所有依赖进行交互，而应该专注于具体的事情，去看这些项目的 struct ，他们的依赖基本上也是可控的，大部分都是最最多十几个这样了。如果一个组件依赖过多，可能需要思考是不是该重构了。

当然对于大规模多人的业务需求迭代频繁的大型 Web 应用项目，我觉得依赖注入 DI 框架还是有价值的，因为这种迭代变化频繁的项目可能会有很多业务驱动的 Service ，用 DI 框架能够提升开发效率，让搬砖的 IT 民工（比如我）不需要关注很多细节，但另一方面微服务模式一定程度上也降低了单体的复杂度，缓解了此类问题

@kneo 我觉得整体的交流讨论本身还是有益的，像我之前也一直把 goroutine 称呼为协程（ coroutine ），虽然我知道现在 goroutine 是抢占式的，但这么叫也说明我自己对于计算机系统的理解不够深刻。

就中文互联网而言，看到的诸多讨论、书籍，包括我之前面试字节的时候面试官都直接将 goroutine 称为“有栈协程”，这个偏差认知在国内应该是很普遍深入了，但反而是有引导到正确认知的价值，后续我应该也会尽自己所能去传播这类正确的知识。

@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

完成度很高👍