【分布式系统百科】Percolator 模型：Google 的乐观事务方案
内容提要
Percolator是Google在Bigtable上构建的分布式事务系统，用于解决搜索引擎增量索引更新问题。它通过data、lock、write三列结构编码事务状态，采用两阶段提交（Prewrite/Commit），以主键提交作为原子提交点，消除专用协调者依赖。系统提供快照隔离，支持冲突检测与锁清理。TiDB等产品在此基础上进行了工程优化，如悲观锁、Async Commit等。
延伸解读
设计动机：从全量重建到增量更新
Percolator 的诞生源于 Google 搜索引擎索引更新的实际需求。在它之前，MapReduce 全量重建索引需要数天，导致新网页无法及时被检索。增量更新虽然快，但需要跨行原子性来保证索引一致性。Percolator 正是为解决这一具体问题而设计，而非通用数据库，这决定了其乐观并发、低冲突率的假设。理解这一背景，有助于把握其设计取舍的合理性。
三列结构与原子提交点
Percolator 的核心创新在于将事务协调状态编码进数据本身，通过 data、lock、write 三列实现。主键的提交（写入 write 并删除 lock）是原子提交点，由 Bigtable 单行事务保证。这一设计消除了对专用协调者的依赖，任何客户端都能通过读取主键状态判断事务命运，从而避免了经典 2PC 的阻塞问题。理解这一机制是掌握 Percolator 的关键。
锁清理与崩溃恢复
Percolator 的容错依赖于锁清理机制。当遇到残留锁时，通过检查主键状态决定前滚（roll forward）或回滚。若主键已提交，则补全副键提交；若未提交且锁超时，则清理锁和数据。这一过程无需协调者，任何客户端均可执行，体现了“数据即协调”的范式。TTL 与心跳机制用于平衡慢事务与崩溃检测，是生产环境的重要考量。
工程化改进：TiDB 的实践
TiDB 将 Percolator 落地于 TiKV，并针对生产环境做了多项优化：悲观锁模式解决高冲突场景下的回滚浪费；Async Commit 减少一次 Raft 往返；1PC 在单 Region 事务中跳过两阶段。这些改进弥补了原始论文的局限，但也引入了新的复杂度。理解这些差异有助于评估 Percolator 模型在不同场景下的适用性。
Q&A
Percolator 是什么？它主要解决什么问题？
Percolator 是 Google 在 2010 年提出的分布式事务处理系统，构建在 Bigtable 之上，用于解决大规模增量索引更新问题。它通过 data、lock、write 三列结构实现跨行事务，支持快照隔离，消除了对专用协调者的依赖。
Percolator 如何实现分布式事务？它的核心设计是什么？
Percolator 的核心设计是将事务协调状态编码到数据本身。它利用 Bigtable 的多版本机制，为每行维护 data、lock、write 三个列族：data 存储实际数据，lock 存储锁信息，write 存储提交记录。通过两阶段提交（Prewrite/Commit）实现原子性，主键提交作为原子提交点。
Percolator 如何解决协调者故障问题？
Percolator 消除了专用协调者，事务状态存储在 Bigtable 中。任何客户端都可以通过读取主键行的 lock 和 write 列来判断事务状态，从而接管恢复。如果主键有锁，事务未提交；如果有 write 记录，事务已提交。这避免了经典 2PC 的阻塞问题。
Percolator 提供什么隔离级别？它有哪些局限性？
Percolator 提供快照隔离（Snapshot Isolation），只阻止写写冲突，不防止写偏斜等异常。局限性包括：依赖集中式 TSO 作为性能瓶颈，原始设计仅支持乐观并发控制，冲突率高时性能差，且不提供可串行化。
TiDB 在实现 Percolator 时做了哪些工程优化？
TiDB 在实现 Percolator 时做了多项优化：使用 RocksDB 的三个 Column Family 对应三列；引入悲观锁模式以处理高冲突场景；实现 Async Commit 减少提交延迟；支持 1PC 优化单 Region 事务；以及 Pipelined 悲观锁降低加锁延迟。
Percolator 与经典 2PC 的本质区别是什么？
Percolator 与经典 2PC 的本质区别在于：经典 2PC 依赖专用协调者，原子提交点在协调者的 WAL 中，协调者故障会导致阻塞；而 Percolator 将事务状态编码在数据中，原子提交点为主键行的单行事务，任何客户端都能读取主键状态进行恢复，消除了阻塞问题。
Percolator 的锁清理机制是如何工作的？
Percolator 的锁清理机制基于主键状态判断：遇到副键锁时，读取主键的 lock 和 write 列。若主键有 write 记录，则事务已提交，执行前滚（roll forward）补全副键；若主键无锁且无 write，则事务已中止，清理副键；若主键锁未超时，则等待；若超时，则清理主键和副键锁。
Percolator 的时间戳预言机（TSO）有什么作用？它有什么缺点？
TSO 提供全局严格单调递增的时间戳，用于事务的开始和提交。每个事务需要两次访问 TSO，因此 TSO 的吞吐量限制了系统事务速率，且是单点故障，需要高可用部署。
