【TiDB理论知识04】TiKV-分布式事务与MVCC

分布式事务

下面一个事务里面有两个更新,分别将id=1的Tom改为Jack,将id=2的zhangsan 改为 lisi。在MySQL中这个事务很普通，但是在分布式数据库TiDB 中的会遇到什么问题呢？

sql 复制代码

begin;
(1,'Tom') --> (1,'Jack')
(2,'zhangsan') --> (2,'lisi')
commit;

比如(1,'Tom') 存储在一个TiKV中，(2,'zhangsan')存储在另一个TiKV中，

当我完成修改操作(1,'Tom') --> (1,'Jack') 数据所在的TiKV并提交后，存储(2,'zhangsan')的TiKV不可用了，这样就出现了一个事务中一部分提交修改持久化，一部分未提交的状况，破坏了事务的原子性。

TiDB采用Google的模型解决这个问题

通过一个只修改一行的事务了解事务是如何存储在TiKV中的。

begin; 从PD中获取事务开始的时间戳 start_ts

接下来会把修改的数据读取到内存中，

commit;两阶段提交；第一阶段 prewrite阶段，写两个CF, 分别为default CF 和 Lock CF。将内存中修改的数据写入到TiKV节点中，将锁信息写入到TiKV节点中。第二阶段 commit阶段，从PD中获取事务结束的时间戳commit_ts。

乐观锁：在提交commit的时候将锁信息写入到TiKV ,其他会话感知不到

悲观锁：将锁信息提前写入到TiKV中，其他会话可以感知到。

目前讨论的按乐观锁讨论

事务中，TiKV节点会有三个CF 分别存储为

①default CF 存储修改的数据 ，put <3_100,Frank > 在 (ID_时间戳，修改的新值)，只存储修改的新值，因为新数据永远在上面

put <3_100,Frank > 修改

put <3_100,Frank > 插入

delete <3_100,Frank > 删除

②Lock CF 存储锁信息 ，只给事务修改的第一行加一把主锁，其他修改的行指向主锁。

锁结构<3,(w,pk,3,100,...)> w代表写锁，pk代表主键，3 代表key? ,100代表开始时间戳

③ 在Write CF中写入提交信息 ，commit 之后两阶段提交的第二阶段，

<3_110,100> <业务ID_提交时间,事务开始时间>

然后写入锁信息的清理，不是删除 LOCK CF中数据，而是插入一条数据例如

<3,(D,pk,3,100,...)> D 代表删除

write CF 不单单会记录提交信息，当这一行的数据长度小于255字节时，还能写数据的修改。

分布式事务解决的关键点：只给修改的第一行加一把主锁，其他行加的是锁的指向，指向第主锁。分布式事务原子性，取决于主锁。

put <1_100,Jack> 业务id_事物开始的时间戳，

<1,(W,pk,1,100...)> 只给修改的第一行加一把主锁，其他行加的是锁的指向，指向第主锁

put<2_100,Candy>

<2,(w,@1,2,100...)> 存储的是锁的指向，指向的是主锁。

如果需要修改很多数据，这些数据在修改期间都不能读写，那严重影响了数据库系统的并发性。

解决上面的方法：写确实不能再写了，因为这些数据在修改。但是可以读。

其他数据库也有MVCC。