分布式事务

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

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的存储

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

事务流程

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

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

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

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

悲观锁：将锁信息提前写入到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字节时 ，还能写数据的修改。

分布式事务在TiKV的实现

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

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

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

put<2_100,Candy>

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

MVCC

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

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

其他数据库也有MVCC。