我在大量项目里都用了 https://github.com/golobby/container ，支持注解式注入和懒加载，很好用。

其实很多人开发 Go 并没有想清楚以下问题，直接短平快，但是大型项目里往往发现代码越写越乱：
1 ，程序初始化一次性任务、定时任务、长运行服务之间如何安排启动顺序；
2 ，命令行解析和配置文件层级及优先级关系
3 ，RPC/GRPC 服务业务报错/系统报错，错误代码处理
4 ，服务 SIGTERM 优雅退出处理
5 ，日志等级管理（ DB ，rpc ，grpc ，resty ）
6 ，单例管理（如*gorm.DB ）

我也是迭代了很多项目，慢慢把这么多东西都抽离成了一个自用独立框架的

2025/5/7
洛杉矶 West 7 Center 停电

West 7 Center 楼中的一个托管机房停电，Coresite 托管在当中的机器受到影响。
据说 AB 两路电全断，已知多个商家受影响：

DMIT 洛杉矶 (官方已发通知)
搬瓦工洛杉矶 v66XX 节点/DC1 (官方已发通知)
ZgoCloud 洛杉矶 (官方已发通知)



当然我们的机房不是这种小云商，但 AB 两路电断掉的确不是什么不可能事件。
断电期间有 BCP 计划，断电恢复不了有 DRP 计划，前提是数据整体状态一致，分布式系统中每个成员的世界状态是相同的，那么来电就能起。否则一边扣钱一边没扣钱（但返回成功），一边下单了一边订单找不到，世界状态就乱了。

分布式系统中，真的需要对每个可能掉了的持久化都进行 peer to peer 对账检查吗？那就太复杂了。

听了大家说了这么多，收获颇丰，感谢大家。

其实这个问题在我这里产生的根源就是在分布式系统中。单体状态自己说了算，灾难恢复回来是什么就是什么。而分布式系统就需要考虑一致性了。

TCC 分布式事务环境下，正如 @weirdte 所说，“返回失败不一定是真的失败，但返回成功是一定要成功的”。 如果被调用方返回成功，但结果却因未落盘而回滚，调用方根本不会知道有这么个回滚节点。回滚节点也不知道有什么应该做而没做的事。

事后对账当然是一个办法，但很多时候对账并不能挽回损失。例如扣减余额这种事如果回滚，肯定要有人背锅了。

似乎解决方法就是双写/强制落盘，不知道例如银行、券商这样的系统，对于涉及钱的跨系统的一致性，除了对账，在技术上是如何实践的呢？又如果性能要求极其苛刻，有什么更好的优化方案？

又从业务角度而言，问题归结为：防止数据回滚，是不是应该成为每一个程序员在开发分布式系统时必须考虑的标准设计规范，还是，程序员不用管，交给 DBA ？

@comlewin 可能是我没表述清楚，我的核心 concern 是落盘 fsync()失败，原因可能会有很多，掉电只是其中之一。

@ivvei 数据总要有地方落盘，落盘就有你落了我没落的情况发生。
假设一个 TCC 事务，被调用方反馈说我做完了，调用方因此完成了这次 TCC ，但此时被调用方突然崩了，数据没落盘，TCC 事务看似做完了实则没做完。
但你要被调用方落盘吧，性能又差了……

UPS 肯定能解决一部分问题，剩下的例如操作系统内核崩溃这种 UPS 无法解决的问题，似乎还有风险。
核心 concern 是 fsync()没执行

pve ，
三个 ubuntu 用于学习研究各种 k8s 集群部署方式
一个 win ，自动爬取某论坛 8K 高清 VR 电影种子并下载
然后部署了一堆自己的脚本，容器，数据库，下载 A 股/币的 K 线，整合并进行行情监控。

别想了， 中介和房东一伙的，早逃之夭夭了。我自己做房东的我知道，哪有付定金才见面的道理？
以后一定要记住，你手里拿着钱，你是大爷，别人求你才对，你不到最后一刻不要把钱交出去。
下次找有门店的靠谱中介吧……这钱你要回来的时间成本太大了。

我面试的一个原则是，要尽可能激发、探索、引导面试者展现出自己所有的能力，包括面试者的知识广度，及他自己熟练的领域的技术深度，以及解决新问题的思路和能力，三者缺一不可。不能做到这一点的面试官都是失败的面试官。

常见的几种失败问题，我的同事有时候也会问，但我非常反感：
1 ，自己超级熟悉而大多数人不熟悉的问题。
2 ，无法鉴别面试者能力，知道就是知道不知道查一查也能知道的问题。
3 ，面试者容易准备的问题，如八股文。

一般我会准备几个实际的技术挑战问面试者，先让面试者铺开知识面，看看考虑问题是否全面，然后让他自己找两个点，我选两个点，深挖下去。
最后问问他，你有什么很厉害的能力没有来得及在刚刚的面试过程中展现出来的吗，可以跟我聊。

这样的面试会给到对方足够的展示机会，而不会像这种拿着狙击枪的面试官，打不中自己预期的 G 点就 fail 面试者。

刚刚下单买了两块 HC550 16T ，比 11 月涨了 100 块左右，而且好多型号都缺货了，怕不是矿盘出得差不多了？

@lengyuqu 一入 VR 深似海，从此磁盘不够用

同建议再买个 CPU ，反正也不贵……CPU 不是不会坏

部署就部署嘛，能看到页面就好了嘛~
至于背后是什么，说不定谁都不在乎，领导可能也就只想跑个 poc 而已。
不过他要是拿着这个 poc 想优化人，那再说……

@Linon 直接用信用卡买？那风控就正常了……c2c 入金会好很多

电动挤牙膏机
我也没想到居然是这个

以我做交易所的经验而言，撮合应该是成功的，撮合性能是不需要担心的，因为全在内存里，交易所的瓶颈在清算。
所以只要完成了撮合，非必要是不回滚的，回滚意味着有些成交了的单都会被撤销，这问题就更大了。
剩下的就是清算了，清算包括：加减你的可用资金/股份，更改你的订单状态等。这些事情的确可以慢慢做，如果遭遇系统故障，晚上发生也不稀奇，你以为晚上才成交，其实早就在白天就被撮合好了，晚上只是改个订单状态而已，在此之前你动弹不得。
交易所在面临订单积压的时候的确挺难的，所有的订单操作（挂单、撤单）都要经过撮合引擎，所以不能简单地把一个撤单操作短路，因为原始订单说不定已经在引擎里被撮合了。
最后就是一旦积压订单量太大，前端肯定会停止收单，表现出来的就是啥操作都进不去，因为后面已经消化不良了。

写了几年 Go 之后你再让我回去写 Java 或者什么 SpringBoot ，我都不想写。

亏啥都不能亏内存啊，64GB 就能很爽了，我办公室的工作机和家里的工作机都是 128GB ，家里的洋垃圾服务器 256GB 。