Percolator 分布式事务与两阶段提交优化

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

为什么难：单页好写，跨页难

河源村只有一面大石墙账本，每块石板是一个村民的账户。账房先生可以一口气把王婶石板上的 100 改成 70，因为单块石板的刻写是原子的——要么完成，要么原样；但一次以物易物要同时改王婶、李叔、赵伯三块石板。他只有一支笔，改到第二块时如果卡住，村民们就会看到一半新账、一半旧账。

把石墙换成 BigTable，村民换成数据行，问题完全一样：BigTable 有能力保证单行操作原子性，却没有跨行事务原语。Percolator 要做的，就是在这层存储之上补出跨行 ACID。原子性、一致性、隔离性、持久性，就像一张借条的四要素，缺了任何一项，账本都无法让人放心。

难点来自三处：原子性无法一次覆盖多行；协调动作发生在网络另一端，通信可能丢失；任何进程都可能随时崩溃。因此，需要一套让所有参与者都认可的记账规矩。

所以，问题的本质不是“写不快”，而是“怎么让多个远程写动作看起来像一个动作”。

核心思想：把事务状态写进账本

账房先生定下三条规矩：第一，改账前先插红布条占位；第二，新值必须带上墨迹年号；第三，所有相关红布条中必须指定一条“总布条”，总布条拔掉才算成交。

换成技术语言，这三条规矩就是锁、时间戳和主锁。Percolator 不是一个独立数据库，它更像一组客户端逻辑，坐在 BigTable 肩上。事务状态不在某个协调者进程的私有内存里，而在 BigTable 的行里。这样一来，状态天然持久化，不需要额外的日志服务器来记住“我正在做什么”。

这套思想我们叫它事务状态机：一次跨行操作，要么停留在预写，要么走到提交，要么退回回滚。真正聪明的不是“不犯错”，而是“犯了错之后，账本上还留着足够的信息让别人补救”。

这就是 Percolator 的立身之本：把事务的“记忆”放进存储，而不是放进容易丢失的协调者内存。

数据模型：石板上三个凹槽

每块石板被分成三个凹槽：数据区、红布条区、年号区。数据区写真实账目，红布条区挂锁标记，年号区记录“这笔账是什么时候正式落印的”。

在 BigTable 中，一个 row key 就是一块石板的编号，一行可以包含很多列。Percolator 要求每个需要事务保护的单元格都有三种列：data 列存业务值，lock 列存锁记录，write 列存提交时间戳。每个列还可以保存多个时间戳版本，就像同一块石板上能留下不同年份的墨迹。

更准确地说，data 列在预写阶段写入新值，但版本挂在 start_ts 上；write 列在提交阶段写入，版本挂在 commit_ts 上，并且指向对应的 start_ts；lock 列则是在预写时插入、在提交或回滚时删除。

这个模型让“跨行事务”变成“跨行操作列”，而列本身又是 BigTable 和分布式存储擅长管理的对象。

快照隔离：戴上一副时间眼镜

账房先生给每个查账的人发一副“时间眼镜”，设定截止年号。戴上后，只能看到截止年号之前已经正式落印的内容；那些红布条还没拔、只是预写的墨迹，在眼镜里自动消失。这样，即便账房先生正在处理一笔跨三块石板的交易，查账的人也不会看到一半新一半旧的怪象。

技术上的名字叫快照隔离，底层是 MVCC（多版本并发控制）。每个事务开始时申请一个 start_ts，之后所有读取都基于这个时间戳做快照。因为每个值都有版本，读操作可以绕过正在写的锁，直接读旧版本。

于是读者和写者不再互相堵路：写者用锁处理冲突，读者用时间戳处理一致。

两阶段提交：先举旗，再落印

第一阶段是预写：账房先生先在王婶、李叔、赵伯三块石板上写下新值，再各插一根红布条。如果有一块石板已经被别人插了旗，他就知道冲突了，赶紧把自己刚插的旗拔掉，整个交易不算。

第二阶段是提交：只有所有旗都插好之后，账房先生才会去拔“总布条”——也就是主锁。主锁所在的石板被称为 primary row。主行提交成功，事务就有了不可撤销的结论；之后再去拔其他次行的旗，只是完成收尾。

这个“先写主行、再写次行”的顺序，是两阶段提交的灵魂。Percolator 的优化在于：主锁和主写记录都放在 BigTable 的行里，而不是放在一个孤零零的协调者日志里。协调者进程崩溃了，后来者可以看主锁自己判断。

这样，两阶段提交不再依赖某个“永不崩溃”的协调者，而是依赖“账本上总布条的状态”。

故障恢复：主锁一锤定音

如果账房先生写到一半，雷暴断电，下一位账房先生看到某块石板上插着红布条，该怎么办？他不需要给前任打电话，只需要去看“总布条”。

如果总布条还在，说明事务还没到提交点，于是把所有相关石板上预写的新值和红布条都擦掉，完成回滚。如果总布条已经不在了，并且主行年号区有正式写记录，说明这笔交易已经成交，他便主动替前任把其他次行的红布条拔掉，完成提交。

这就是主锁一锤定音的威力。因为主锁状态存在 BigTable 里，任何一个后来者都可以接管恢复过程，系统不再有单点协调者。

所以，Percolator 的故障恢复不是靠“谁的电力足”，而是靠“账本上留下了足够多的线索”。

TiKV 实践：从账本规矩到工业级系统

TiKV 把 Percolator 的规矩搬到了 Rust 实现的分布式 Key-Value 层中。它的每个 key 对应一行，事务同样使用 start_ts、commit_ts、锁列和主锁。跨 Region 的写入，靠的就是同一套两阶段提交骨架。

但 TiKV 不是无脑照搬，它做了不少工程优化：异步提交可以让客户端少等一次次行提交的网络往返；悲观事务对热点行提前加锁，减少乐观重试的代价；大事务支持则让更多业务场景敢于让多个 key 同时参与同一个事务。

正因为 TiKV 在工业界验证了这套思路，Percolator 才成为 NewSQL 与分布式数据库绕不开的设计蓝本。它真正迷人的地方，不是两阶段提交本身，而是“把决策状态放进存储”这个看似简单却影响深远的优化。

从河源村石墙到 TiKV，Percolator 用一套朴素的规矩，解决了分布式系统里最难的“多行一致性”问题。

AI 应用场景

Python 演示

class PercolatorSim:    def __init__(self):        self._ts = 10        self._data = {}        self._locks = {}        self._writes = {}        self._data[('wang', 'balance')] = 100        self._data[('li', 'balance')] = 50     def _next_ts(self):        self._ts += 10        return self._ts     def _prewrite(self, row, col, new_value, start_ts, primary):        key = (row, col)        if key in self._locks:            return False        self._locks[key] = {            'new_value': new_value,            'start_ts': start_ts,            'primary': primary        }        return True     def _rollback(self, key):        self._locks.pop(key, None)     def _commit_row(self, row, col, commit_ts):        key = (row, col)        lock = self._locks.pop(key, None)        if lock is not None:            self._data[key] = lock['new_value']            self._writes[key] = commit_ts     def transfer(self, from_row, to_row, amount):        start_ts = self._next_ts()        col = 'balance'        primary = (from_row, col)        from_value = self._data[(from_row, col)] - amount        to_value = self._data[(to_row, col)] + amount        if not self._prewrite(from_row, col, from_value, start_ts, primary):            return None        if not self._prewrite(to_row, col, to_value, start_ts, primary):            self._rollback((from_row, col))            return None        commit_ts = self._next_ts()        self._commit_row(from_row, col, commit_ts)        self._commit_row(to_row, col, commit_ts)        return commit_ts     def read(self, row, col):        return self._data.get((row, col))  if __name__ == '__main__':    sim = PercolatorSim()    print('before:', sim.read('wang', 'balance'), sim.read('li', 'balance'))    ts = sim.transfer('wang', 'li', 30)    print('after:', sim.read('wang', 'balance'), sim.read('li', 'balance'), 'commit_ts:', ts)

1. if key in self._locks: return False如果锁列已有红布条，说明冲突，预写失败。
2. self._locks[key] = {'new_value': new_value, ...}把预写的新值和事务开始时间记在锁里。
3. if not self._prewrite(to_row, ...): self._rollback((from_row, col))任一预写失败，就清理已经插上的旗。
4. lock = self._locks.pop(key, None)提交时先拔掉锁，模拟主行提交。
5. self._data[key] = lock['new_value']拔锁后把新值正式写进账本。
6. self._writes[key] = commit_ts在写列留下提交时间戳，表示这件事已经落印。
7. self._data.get((row, col))读操作只读 data 列，永远看不到还没提交的锁内新值。

常见误区

面试题