分布式事务
下面一个事务 里面有两个更新,分别将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。
