TiDB 如何实现分布式事务的 ACID 特性？

Question

在使用TiDB实现分布式事务时，一个常见问题是：TiDB如何在保证高并发写入性能的同时，通过Percolator事务模型实现强一致性ACID特性？特别是在跨多节点的分布式场景下，TiDB如何利用全局授时服务（PD）生成单调递增的时间戳来协调事务的读写冲突，并通过两阶段提交（2PC）确保原子性与隔离性？此外，当网络分区或节点故障发生时，TiDB如何借助Raft协议保障事务日志的持久化与副本一致性，从而满足持久性要求？理解这些机制对优化事务性能和排查异常至关重要。

Answer 1

1. 分布式事务基础：TiDB中的ACID保障机制概述

TiDB作为一款兼容MySQL协议的分布式NewSQL数据库，其核心目标之一是在高并发、大规模数据场景下实现强一致性与高可用性。为达成这一目标，TiDB采用Percolator事务模型，结合全局时间戳服务（Placement Driver, PD）和Raft共识算法，构建了一套完整的分布式事务处理框架。

在传统单机数据库中，ACID特性由本地锁机制和WAL日志保障；而在分布式环境下，事务可能跨越多个存储节点（TiKV），这就要求系统必须解决跨节点的时间协调、冲突检测、提交原子性等问题。

2. 全局授时服务PD：单调递增时间戳的生成与作用

Pd（Placement Driver）是TiDB集群的“大脑”，负责元数据管理、负载均衡以及最重要的功能——提供全局唯一且单调递增的时间戳（Timestamp Oracle, TSO）。

每个事务开始前，TiDB Server会向PD请求一个StartTS（开始时间戳），用于标识该事务的快照版本。所有读操作基于此时间戳进行多版本并发控制（MVCC），确保可重复读隔离级别。

当多个事务并发执行时，PD通过TSO服务保证时间戳的全局有序性，从而避免了因时钟漂移导致的因果错乱问题。

组件	职责	关键机制
TiDB Server	SQL解析、事务调度	2PC协调者
PD	全局时间分配、元信息管理	TSO服务
TiKV	键值存储、事务执行	Raft + MVCC
Region	数据分片单元	副本一致性维护

3. Percolator模型详解：基于MVCC的分布式事务流程

Percolator源自Google论文，是一种基于列族存储的分布式事务协议，被TiDB深度改造并应用于TiKV层。其核心思想是将每行记录拆分为多个列：Primary、Write、Lock 和 Data。

1. 客户端发起事务，TiDB从PD获取StartTS
2. 读取阶段使用StartTS查询对应版本的数据（MVCC可见性判断）
3. 写入阶段不直接落盘，而是设置临时Lock和预写日志（Write Record）
4. 进入两阶段提交流程

4. 两阶段提交（2PC）实现原子性与隔离性

在Percolator模型中，2PC由TiDB作为协调者驱动：

• 第一阶段（Prewrite）：对所有涉及的Key尝试加锁并写入临时数据。若任一Key失败，则整个事务回滚。
• 第二阶段（Commit）：仅当所有Prewrite成功后，使用CommitTS提交事务，并清除Lock标记。

CommitTS也来自PD，且必须大于StartTS，确保版本顺序正确。这种设计使得即使网络延迟或分区发生，也能通过时间戳排序判定事务先后关系。

func (txn *Transaction) Commit() error {
    commitTS := pdClient.GetTS()
    for _, key := range writeKeys {
        if !tryCommit(key, commitTS) {
            return ErrCommitFailed
        }
    }
    unlockKeys(writeKeys)
    return nil
}
    

5. Raft协议保障持久性与副本一致性

在TiKV中，每个Region有多个副本（通常为3个），构成一个Raft组。所有写操作（包括Prewrite和Commit）都需经过Raft共识复制到多数派节点才能确认成功。

这意味着即使某个TiKV节点宕机或网络分区，只要多数副本存活，事务日志仍能持久化保存，满足Durability要求。

Raft还解决了脑裂问题，通过Leader选举机制确保同一时刻只有一个主节点接受写请求，防止并发修改破坏一致性。

graph TD
            A[TiDB Server] -->|StartTS| B(PD Cluster)
            A -->|Read with Snapshot| C[TiKV Node 1]
            A -->|Prewrite Request| D[TiKV Node 2]
            A -->|Commit Request| E[TiKV Node 3]
            D -->|Raft Log Replication| F[Replica on Node 1]
            E -->|Raft Log Replication| G[Replica on Node 2]
            F -->|Majority Match| H[Commit Entry]
            G --> H

6. 故障场景下的事务恢复与GC机制

当节点故障或网络分区时，可能存在未完成的事务残留Lock记录。TiDB通过定时启动的GC（Garbage Collection）组件清理过期版本和死锁。

此外，TTL（Time To Live）机制限制事务最长运行时间，超时自动回滚，防止长时间持有锁影响其他事务。

对于处于“不确定状态”的事务（如Commit阶段中断），TiDB可通过检查Primary Key的状态来决定是否重试或回滚，确保最终一致性。

监控系统（如Prometheus + Grafana）可用于观测2PC延迟、锁等待、TSO压力等关键指标，辅助性能调优。

7. 性能优化建议与常见问题排查路径

尽管Percolator提供了强一致性保障，但在高并发写入场景下可能出现性能瓶颈：

• 热点Region导致写入集中，可通过SPLIT TABLE分散负载
• 频繁的2PC通信增加RTT开销，推荐批量提交减少交互次数
• PD成为性能瓶颈时，可启用TSO分流（如Follower Read增强）
• 长事务阻塞GC，应避免大事务或显式控制事务边界

典型异常包括Write Conflict、Key Already Locked、Resolve Lock Timeout等，需结合日志追踪Lock持有者及事务生命周期。