latifrons

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 面试者。