TiDB从0到1系列

• TiDB-从0到1-体系结构
• TiDB-从0到1-分布式存储
• TiDB-从0到1-分布式事务
• TiDB-从0到1-MVCC

一、事务定义

这属于老生常谈了，无论不管是传统事务还是分布式事务都离不开ACID

• A：原子性
• C：一致性
• I：隔离性
• D：持久性

二、隔离级别

同样都是老一套东西，主要应对脏读、幻读、不可重复读等问题

• 读未提交
• 读已提交
• 可重复读
• 可串行化

在TiDB中，实现了快照隔离 (Snapshot Isolation, SI) 级别的一致性：
事务只能看到早于它开始时刻之前提交的其他事务。

如图，T2是无法访问到T1事务的内容，T3是可以访问T1、T2事务中的内容。

而快照隔离基本是基于Percolator事务模型原理实现的

Percolator 模型

Percolator模型是Google在2010年提出的一种分布式事务处理模型，其设计目标是在大规模分布式系统中实现高效的事务处理。Percolator是一种乐观的事务模型，写写冲突被延迟到事务提交时才会进行检测。可见性与冲突检测依赖于事务的开始时间戳以及提交时间戳。
Percolator模型是一个典型的通过两阶段提交(2PC)进行分布式事务协调的实现。事务的实现主要依靠三个参与者：Percolator客户端、BigTable TabletServer、Timestamp Oracle(TSO)。按照2PC的要求分为两个步骤：PreWrite和Commit。
Percolator模型中，事务执行的过程可以概括为以下几个步骤：

• Percolator客户端作为事务协调者，负责发起事务请求。 BigTable TabletServer接收并处理事务请求。
• Timestamp Oracle(TSO)提供时间戳服务，确保事务的顺序性和一致性。
• 在PreWrite阶段，TSO分配一个时间戳给事务，BigTable TabletServer将事务的写请求记录在本地。
• 在Commit阶段，TSO根据事务的时间戳和BigTable TabletServer的记录，决定是否提交事务。
• Percolator模型的一个创新点在于，它依靠对时间戳的使用和BigTable的单行事务，实现了跨行事务。由于某一行数据可以位于不同的BigTable的TabletServer之上，所以该事务也是跨节点的。

这里也再次印证TiDB中为什么事务在开始前和提交时会分别获取一次TSO。

三、TiDB-分布式事务（单行）

1、Begin（开启一个事务）

此时会从PD获取一个TSO，假设为100

2、SQL

update test set name=‘Frank’ where id=3；

3、Commit（提交事务）

此时再次从PD获取一个TSO，假设为110

4、进入2PC阶段

• prewrite阶段
  
  将数据：3（id）_100（事务开始的TSO）,Frank（数据内容）记录在默认链表中
  将锁信息：3（id），W（写锁），pk（主锁），3（id），100（事务开始的TSO）,Frank（数据内容）记录在锁链表中
• commit阶段
  
  将锁信息：3（id）,D（已释放的锁），pk（主锁），3（id），100（事务开始的TSO）,Frank（数据内容）记录在锁链表中
  将数据：3（id）_110（事务提交的TSO），100（事务开始的TSO）记录在更新链表中

这里有两个细节
1、TiDB中的DML都是以追加的方式实现。
做一个对比
传统关系型数据库：

begin;insert into test(id,name) values(1,'zmz');commit;
begin;update test set name='MySQL' where id=1;commit;
begin:update test set name='TiDB' where id=1;commit;

此时底层其实只有一条数据，就是id:1\name:TiDB

TiDB数据库：

begin;insert into test(id,name) values(1,'zmz');commit;
begin;update test set name='MySQL' where id=1;commit;
begin:update test set name='TiDB' where id=1;commit;

此时底层其实是有三条数据的

id:1\name:TiDB
id:1\name:MySQL
id:1\name:zmz

那么当我们在TiDB查询test表时会查到3条数据吗？当然不会，而是根据提交事务的TSO读取到最新的数据。
那么长期看来是不是会有非常多的冗余无效数据呢？当然也不会，GC模块会定时清理掉历史版本数据。

2、上面提到主锁机制
TiDB的分布式事务中，假设一条事务涉及多行数据，那么将采用主锁机制：只对事务的第一行数据上锁，后面的数据跟随第一行的主锁。

四、TiDB-分布式事务（多行）

1、Begin（开启一个事务）

此时会从PD获取一个TSO，假设为100

2、SQL

update test set name=‘Jack’ where id=1；
update test set name=‘Candy’ where id=2；

3、Commit（提交事务）

此时再次从PD获取一个TSO，假设为110

4、进入2PC阶段

• prewrite阶段
  
  这里与单行数据事务最大的不同是，第二行数据的加锁信息：
  2（id），W（写锁），@1（跟随主锁1），2（id），100（事务开始的TSO）,Candy（数据内容）

• commit阶段
  
  主锁释放后，跟随锁一起释放。
  再次强调，这里的释放不是删除，而是插入新的锁清理记录。

彩蛋

TiDB可以动态调整事务的隔离级别和锁的实现方式

• 根据transaction_isoiation设置隔离级别
• 根据tidb_txn_mode设置乐观锁还是悲观锁