@0x93ee 其实我做这一行这么多年，我一直觉得发币的终极形态就是提供一种方式，让人愿意为财产、信仰、权力、兴趣等一切可以买单的东西买单。降低投资门槛，买一个信仰或者是现在未来的权益，MEME 如此，价值币如此，股票如此。从这一角度来说，我相信站长，所以我就投资$V2EX 。我当然希望他有功能，但是我更信赖的是站长的态度，纯粹，干净，他不一样。

$V2EX 我不认为他是 MEME ，我认为他是 V 站的股票。
我长期持有了，黄金手拿个几年再说。至于今后站内经济系统是不是可以用$V2EX 重构，我觉得还真可以。

如果实在受不了 k8s/k3s 的学习曲线的话我推荐 Hashicorp 的 Consul+Nomad ，单文件轻量级，一样可以做容器编排/健康检查/服务发现/持久化，我们在生产上几十个服务上百个容器实例，很稳。

买点 V2EX 币，然后忘了它

如果开发项目比作打仗，你得至少知道枪的用法，你得至少有能力解决一些基础数据结构和算法问题（这些正规的本科都会教，当年我们本科也手撸红黑树），但是真的要打仗的话，光会用枪可远远不够。
LeetCode 就是让你把枪玩到炉火纯青，拆枪组装枪 10 秒内完成，到最后枪人一体，登峰造极。

面试新兵蛋子的时候也没法问什么深的，那就问问你对枪熟悉不熟悉吧。

但真开发项目了，你会发现你用的都是手榴弹火箭弹飞机大炮地雷啥的，枪，会就可以了。

事实上鉴于人类技术水平限制，很多时候并不能说明白药为什么能治病，但是只要能治好，那我可以接受任何形式的药，人生在世一百年，结果最重要。

但前提是你得证明病是你这个药治好的，而不是我心情好了自然好了。双盲起码得做一个吧？

蓝犀牛，搬多少东西都是明码标价的，小东西不收钱，哪里收费一项一项很清楚。我们家几个超大的柜子，他帮你全部拆好包好运下去，那次从早搬到晚，大箱货车塞满了两次（两车东西收两次的钱也很合理）

无脑入 Quest3 ，生态好，多用途，纯看片的话可以买小容量的，但极力推荐大容量的，毕竟还能玩其它的游戏。

片源建议下载 HEVC 编码的 8K 视频，其它编码格式的基本没有看的欲望。

片商建议选 KMP 的（ VRKM-xxx ，SAVR-xxx ），他们的拍摄设备、打光、颜面特化是目前行业里的顶级水平。

@Akitora 给“Android 系统”这个软件翻墙，否则 fcm 推送接不到，一堆软件莫得推送

新冠抗原和先诺欣我现在终年常备，真起病到买到药，除非去医院，否则只能走快递，要至少两到三天。

MT Photos yyds

Lark 不把 fcm （ Android 系统）翻墙的话收不到消息推送了，牛马表示很焦虑。
不知道能不能让 Lark 别走 FCM……

我在大量项目里都用了 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()没执行