高频金融系统如何防止突然断电导致的数据丢失？

[latifrons]

我知道 MySQL ，RocksDB 等数据库其实都有 WAL ，但同样地都依赖操作系统定期将内存缓存中的数据通过 fsync()刷回磁盘。如果此时断电（或者操作系统崩溃），1 秒内的数据可能会丢失。

MySQL：innodb_flush_log_at_trx_commit

https://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 的一个回答： https://chat.qwen.ai/s/0e7d9977-4400-41da-883f-2972893104cf?fev=0.0.85

想请教一下大家，在对数据完备性要求极高的场景下，大家是怎么优化性能的？

[zgsi]

应急电源啊

[nekoneko]

UPS 保平安

[x86]

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

[ghostwind]

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

[ghostwind]

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

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

[opengps]

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

[jvee]

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

[scegg]

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

[scegg]

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

[julyclyde]

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

[latifrons]

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

[scegg]

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

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

[ivvei]

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

[scegg]

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

[julyclyde]

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

[comlewin]

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

[seers]

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

[scegg]

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

[latifrons]

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

[scegg]

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