FoundationDB 中有 Undo 和 Redo 吗？从 TLog、MVCC 到故障恢复

Fri, 14 Aug 2026 10:00:00 +0800

传统数据库通过 Undo Log 和 Redo Log 保证事务的原子性与持久性：Undo 撤销未提交的修改，Redo 恢复已经提交但尚未写入数据文件的修改。那么，在采用分布式事务架构的 FoundationDB 中，是否也存在这两类日志？

简短回答是：

FoundationDB 有承担类似 Redo 职责的 TLog，但通常没有传统意义上的 Undo Log。

这并不意味着 FoundationDB 不支持事务回滚或 MVCC，而是因为它对未提交数据、提交日志和历史版本的组织方式与传统数据库不同。

一、先回顾传统数据库为什么需要 Undo 和 Redo

传统数据库通常允许事务直接修改缓冲池中的共享数据页。数据页何时写入磁盘，与事务何时提交并不完全同步。

因此会出现两种状态。

例如事务把账户余额从 100 改成 80，但随后事务失败：

BEGIN;

UPDATE account
SET balance = 80
WHERE id = 'A';

ROLLBACK;

如果包含 80 的脏页已经写入磁盘，数据库就必须知道原值是 100，才能撤销这次修改。这是 Undo Log 的主要职责。

另一个事务已经执行 COMMIT，但修改可能仍然只存在于内存中的脏页里。如果服务器此时断电，已提交的数据就会丢失。

因此数据库先持久化 Redo Log，再返回提交成功。重启后，即使数据页没有及时落盘，也可以通过 Redo 重新应用修改。

可以把二者概括为：

Undo：事务不应该生效，但修改可能已经进入数据文件。
Redo：事务应该生效，但修改可能还没有进入数据文件。

FoundationDB 并不是把客户端事务中的每次 set 或 clear 立即写入 Storage Server。事务提交前，这些操作首先保存在客户端的事务对象中。