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

拆解 WiredTiger 应用时间戳（oldest/stable/pinned）、事务 read/commit timestamp、快照隔离下的可见性检查，以及 prepared 的 prepare/durable 边界；为 History Store 与 Rollback-to-Stable 提供时间轴。

拆解 BEGIN DEFERRED/IMMEDIATE/EXCLUSIVE 三种模式的取锁时机差异，对照 Berenson et al. SIGMOD 1995 的隔离词汇与官方 Isolation In SQLite 文档；说明单写者约束下 WAL 快照为何天然回避 write skew，并用本机 3.53.2 实测三种 BEGIN 均可提交。

钉住 ATTACH DATABASE 的命名空间规则、super-journal 如何让跨文件事务在 rollback journal 模式下保持原子，以及官方文档明确写明的一条反常识边界：main 库或任一 attached 库切到 WAL 后，跨库事务只在单文件粒度原子，崩溃中间态可能只改了一部分文件；本机 3.53.2 实测跨库 JOIN、跨库事务提交与 DETACH 锁冲突。

本文讨论了FoundationDB的事务处理机制，重点介绍了@transactional函数的使用、冲突检测、自动重试及5秒事务限制。事务在客户端缓冲写入，提交时检查读写冲突，读过的key会影响冲突范围。事务需在5秒内完成，超时将导致失败。文章强调了幂等性的重要性，以确保重试时结果的一致性。

FoundationDB 采用控制面与数据面分离的架构，支持独立扩展。事务处理流程包括获取读版本、提交、冲突检测及日志持久化。本文为系列第一篇，介绍了角色分工及事务路径。

本文讨论了FoundationDB的写事务提交过程，强调提交成功与数据可见性之间的区别。提交由Commit Proxy协调，涉及Sequencer、Resolver和TLog。客户端在提交后依赖TLog的耐久性，但Storage Server的可读性可能会延迟。文章还探讨了批处理、冲突检测及与TiKV的对比，指出了系统设计选择和潜在的工程挑战。

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

TiKV 的悲观锁默认使用内存路径以减少加锁延迟，但在非计划的 Leader 切换时可能会丢失锁。锁的 TTL 动态调整，长事务依赖心跳续期。死锁检测采用集中式方案，Leader 切换时清空历史依赖，存在漏检风险。TiKV 的锁机制与传统数据库相似，需纠正对其“无锁”的误解。

本文讨论了RocksDB的事务机制，包括悲观锁和乐观事务的实现。WriteBatch确保批内原子性，但不处理并发冲突。TransactionDB使用悲观锁进行冲突检测，而OptimisticTransactionDB在提交时检查冲突。WritePrepared优化了两阶段提交的路径。TiKV在分布式层实现事务，RocksDB事务API为本地引擎提供能力，适用于低冲突和高冲突的事务处理场景。

本文讨论了Apache Kafka 3.x中的幂等生产者和事务生产者的工作机制。幂等生产者通过Producer ID和序列号消除重复消息，而事务生产者确保多分区消息的原子性。消费者隔离级别分为read_committed和read_uncommitted，影响事务数据的可见性。Flink与Kafka结合实现了端到端的exactly-once语义，确保数据一致性。

Cloudflare Workflows推出了“事务回滚”功能，允许开发者在工作流步骤中定义回滚逻辑，以处理步骤失败的情况。开发者可以在每个步骤中添加回滚函数，确保在操作失败时安全撤销之前的步骤，保持工作流一致性。这一设计简化了错误处理，提高了多步骤应用的可靠性。

数据库在第十阶段实现了事务、并发控制和用户接口，确保数据的原子性和隔离性。通过锁管理，防止多个连接互相干扰。REPL和TCP服务器使用户能够直接与数据库交互，完成SQL操作。

本文讨论了数据库中的经典故障模式，包括长事务、脏页、死锁和复制延迟，并提供了相应的排查和修复建议，如调整事务超时、优化写入峰值和改用不同的隔离级别。

本文探讨了MySQL InnoDB的Undo Log机制，分析了其核心数据结构、关键算法和状态机，强调了Undo Log对DML延迟和崩溃恢复的影响，并提供了源码阅读路径和实验步骤。同时对比了PostgreSQL的实现，指出两者在隔离语义上的不同，并提醒在生产环境中注意不同版本的实现差异。

本文讨论了Postgres内部的隐性数据损坏问题，包括多事务ID处理、TOAST表缺失块和撕裂页面等情况，这些问题可能导致数据错误而不被察觉。文章强调定期检查数据库完整性的重要性，推荐使用amcheck和pg_amcheck等工具进行监测，以及时发现潜在问题。