我知道 MySQL ，RocksDB 等数据库其实都有 WAL ，但同样地都依赖操作系统定期将内存缓存中的数据通过 fsync()刷回磁盘。如果此时断电（或者操作系统崩溃），1 秒内的数据可能会丢失。
MySQL：innodb_flush_log_at_trx_commit
dba.stackexchange.com/questions/12611/is-it-safe-to-use-innodb-flush-log-at-trx-commit-2

The default value of 1 is required for full ACID compliance. You can achieve better performance by setting the value different from 1, but then you can lose up to one second worth of transactions in a crash. With a value of 0, any mysqld process crash can erase the last second of transactions. With a value of 2, only an operating system crash or a power outage can erase the last second of transactions. InnoDB's crash recovery works regardless of the value.

所以似乎为了数据完备性，innodb_flush_log_at_trx_commit=1 是不可避免的，从而会导致比较严重的性能劣势。
例如 LevelDB ，开启 WriteOptions(Sync=true)后，tps 从 190000/s 骤降为 1200/s.
Qwen3 的一个回答： chat.qwen.ai/s/0e7d9977-4400-41da-883f-2972893104cf?fev=0.0.85
想请教一下大家，在对数据完备性要求极高的场景下，大家是怎么优化性能的？

应急电源啊

UPS 保平安

金融系统连 UPS 都没一个吗？

看你是上游还是下游，如果是下游，可以起一个重发的信号

如果是交易所，比如是上交所 ，你可以去搜索上交所 ups 电源 结果就是：UPS+柴发

证券技术大厦共 10 层，其中地上 8 层，可提供超过 6000 平米的托管机房，采用双路独立的市政电源作为常用电源，配备了 2N 的 UPS 及 N+1 冗余柴发作为备用电源。

银行都是异地多活，多可用区（独立供网供电，独立 ups 电源）。内存都已经可以当硬盘用

双路电源+ups+同城、异地灾备

因为突然断电可能不只是导致数据丢失，不少问题很难快速恢复。
所以不如防止突然断电。

为了实现一个目标，不可能不需要付出其他代价。不然这个目标早就成为标准了。
当需要付出代价的时候，就要看是否值得。
在这个例子上，保证不突然断电就是代价最低的办法。

根本两码事
你这是解决不了问题就直接不承认问题存在啊

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

问题不存在的原因是这个问题不需要被解决。
任何保障“安全性”的设计都会带来“性能”损失。如果为了一个能用更小的代价（解决供电稳定性）来解决“安全性”问题，就不需要因此牺牲“性能”。

如何解决吃垃圾会中毒的问题？那就别吃垃圾。

高频?多高? 都还在用数据库，那估计也高不到哪里去，那么完全可以先写入再确认嘛。没写入的就当没发过。这是上游的做法。如果是下游的话，找上游要一份最新的快照就行，反正以人家的为准

如果要解决系统级（包括硬件和软件）问题，可以考虑 FT 服务器或者支持 FT 的其他设计（比如 vmware 的 FT ）。

那你看看哪个系统敢于“只要上了 UPS 就不需要写日志”的？

金融核心系统不会存在断电的情况，双路电，UPS 电池，柴发，同城这些都是硬性要求

db2 可以使用 dio 直接写盘跳过系统的缓存层

你认为的日志是为了防止掉电设计的吗。

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

对的。但无法跳过硬盘的缓存。因为不需要。db2 的 dio 就是因为操作系统的内存中的缓存可能不受保护。但原因可能不是因为电力，而是包括电力在内的更多原因（例如系统崩溃、大型机的背板故障之类）。
服务器用的 RAID 系统，缓存自己就带电池，或者是 FBWC 这种掉电不会丢数据的设计。

一切软件或者 OS 层面的措施都不如物理防御。

直接上 UPS+柴油发电机。简单暴力可靠。

根据业务对“数据一致性”的要求，必要时牺牲性能的方法包括但不限于分布式事务，或其等价的逻辑层实现。

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

如果是担心数据一致性的问题，考虑分布式事务或其等价的逻辑实现方案。如果不能接受其性能开销，考虑硬件冗余机制（包括电力、硬件 FT 或虚拟化 FT ）。

世界的核心不是石油，就是电磁波。

有些技术的牛角尖可以不用钻那么深，有些事情可以不用技术的思路而是用工程的思路去解决。
怕断电，那就保证不要断电就行了。怕机房爆炸，那增设若干套冗余异地系统和线路就好了。

真的遇上事，服务断了就断了吧，比如机房都被炸了，就没必要想过多技术问题了。

分布式系统的 CAP 定理，只能折中。

同城容灾 异地多活 多可用区 多云 自建机房那就是 UPS 柴发拉满 多演练 保证不断电到电才是硬道理

第一家工作电商公司，在一个园区里，一共 7 层，2-3-4 楼是机房，还有两个异地机房。然后 ups+发电机。有一次园区停电，十分钟发电机就顶上了。三台车，在楼下发了两天。别的单位都在摸鱼，只有我们在上班，领导开玩笑，我就说要把机房搬走，如果要从系统层面想招，那么离世界末日不远了。