去年某支付平台故障，用户转账成功却显示余额未变——钱扣了，对方没收到。技术团队复盘时发现，事务提交后0.3秒数据库崩溃，恰好卡在持久化（Durability）的灰色地带。这不是孤例，金融系统每年因此损失的隐性成本以亿计。
ACID四特性中，持久性是最容易被低估的。原子性保证"要么全做要么不做"，一致性确保规则不被打破，隔离性处理并发冲突——而持久性回答一个更朴素的问题：你点下"确认转账"后，如果服务器下一秒爆炸，这笔钱还算数吗？
持久性不是"保存"，是"幸存"
很多人误解持久性=数据存进硬盘。实际上，它要求事务提交后，其效果必须永久存在，且能抵御任何后续故障——断电、磁盘损坏、操作系统崩溃，甚至数据库进程被kill -9。
原文用PostgreSQL演示了一个极简场景：Alice向Bob转账200元。初始状态两人余额分别为1000和500，事务提交后Alice变为800。关键测试在于——如果在COMMIT执行的瞬间拔掉电源，重启后Alice的余额必须是800，不能回退到1000，也不能变成未定义状态。
这个看似简单的要求，实现起来需要三层防护。第一层是预写式日志（WAL，Write-Ahead Logging）：数据页真正落盘前，先追加写入连续的日志文件。日志是顺序写，磁盘I/O成本远低于随机写数据页，且崩溃后可通过重做（redo）日志恢复。
第二层是检查点机制。数据库定期将内存中的脏页刷到磁盘，并记录一个"一致性位点"。崩溃恢复时，只需从上一个检查点开始重做WAL，而非遍历全部历史。PostgreSQL默认每5分钟一个检查点，这个间隔是性能与恢复速度的权衡。
第三层常被忽略：fsync()系统调用。操作系统为提升性能会缓存写操作，数据库必须显式调用fsync强制刷盘，否则"提交成功"只是写进了内核缓冲区，断电即丢。PostgreSQL的synchronous_commit参数控制这一行为，设为off可提升性能，但持久性降级。
为什么你的"转账成功"可能是幻觉
国内某头部支付平台曾出现过诡异bug：用户收到"转账成功"推送，对方却未到账。根因是应用层与数据库层对"提交"的定义不一致——应用收到数据库的"命令已接收"就返回成功，而非等待WAL真正落盘。
这种设计在高压场景下能提升吞吐量，但牺牲了持久性边界。严格意义上的提交，必须等到WAL写入并fsync完成。PostgreSQL的默认配置（synchronous_commit=on）遵循此原则，但部分云数据库为追求性能指标会偷偷放宽。
另一个隐蔽陷阱是复制延迟。主库提交后立即崩溃，备库尚未同步，自动故障转移可能导致事务丢失。金融级系统通常采用同步复制（synchronous_standby_names）或至少半同步，确保提交时日志已送达指定数量的备库。
原文的测试方法值得借鉴：故意制造崩溃。提交事务后kill数据库进程，或直接用kill -9模拟极端场景，重启后校验数据。这种"破坏性测试"是验证持久性的唯一可靠手段——任何假设"应该没问题"的系统，都会在生产环境被打脸。
从代码到钱的距离
持久性的实现细节直接影响业务设计。以余额字段为例，原文使用INT类型并添加CHECK (balance >= 0)约束，这是防御性编程的典型做法——即使应用层有漏洞，数据库层也能阻止负余额。但INT的上限约21亿，对于高并发系统可能溢出，需改用BIGINT或DECIMAL。
时间戳字段last_updated的默认值CURRENT_TIMESTAMP，在持久性语境下也有讲究。它记录的是事务开始时间还是提交时间？PostgreSQL的CURRENT_TIMESTAMP在事务内恒定，如需精确到提交时刻，应使用clock_timestamp()或事务提交ID（xid）关联日志。
更深层的问题是：持久性保证的是"已提交事务不丢"，而非"用户操作不丢"。用户点击转账按钮后，网络中断、应用超时、数据库连接池耗尽——这些发生在事务开始前的故障，需要业务层的幂等设计来兜底。持久性是数据库的最后一道防线，不是唯一的防线。
某跨境支付公司的架构师曾分享过一个血泪教训：他们为提升性能启用了异步提交，某次机房级故障导致17秒内的2000多笔事务丢失。事后复盘，这些事务的WAL确实写入了操作系统缓存，但未及刷盘。最终赔偿用户损失，并永久关闭了该优化选项。
ACID四特性至此讲完。但技术选型中真正的难题是权衡——全同步复制保障持久性，却拖垮性能；fsync每一事务最安全，但TPS可能暴跌一个数量级。你的系统愿意用多少延迟，换取多高的幸存概率？
热门跟贴