本文讨论了分布式事务中的两阶段提交（2PC）及其在实际应用中的问题，如协调者故障、网络分区和日志丢失等。介绍了Google的Percolator如何解决这些问题，并探讨了Saga和TCC等其他事务处理模式。最后，分析了现代数据库如Spanner、CockroachDB和TiDB的不同解决方案，强调了一致性、可用性和性能之间的权衡。

本文探讨了TiKV如何实现Percolator论文中的data/lock/write模型，分析了TiKV在编码、Prewrite/Commit过程中的调整，包括Rollback记录、短值优化和Lock类型写记录。TiKV将Prewrite的原子性单位从单行事务改为Region的Raft提交，并通过Async Commit和1PC优化减少延迟，满足在线事务的性能需求，展示了TiKV在生产环境中的应用与论文模型的差异。

本文讨论了TiKV的HTAP内核，包括Region、Multi-Raft、PD和TiFlash等组件的功能与交互，重点分析了数据写入路径、事务处理及时间戳调度等关键机制，适合分布式存储工程师和研究生阅读。

TiKV 将 Percolator 的锁、数据和写入三列映射为 RocksDB 的 CF_LOCK、CF_DEFAULT 和 CF_WRITE。通过时间戳的位反转实现 Key 编码规则，确保查询时优先返回最新版本。TiKV 的 MVCC 时间戳由 PD 的 TSO 提供，确保跨 Region 的全局一致性，区别于 RocksDB 的单机快照机制。这三种 CF 共同维护同一逻辑数据，需联合管理。

Percolator是Google在Bigtable上构建的分布式事务系统，用于解决搜索引擎增量索引更新问题。它通过data、lock、write三列结构编码事务状态，采用两阶段提交（Prewrite/Commit），以主键提交作为原子提交点，消除专用协调者依赖。系统提供快照隔离，支持冲突检测与锁清理。TiDB等产品在此基础上进行了工程优化，如悲观锁、Async Commit等。

版本

前言 之前看过 《大规模分布式存储系统：原理解析与架构实战》...