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

2023-12-13 03:42:47

分布式事务

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

文章来源:https://blog.csdn.net/weixin_48154829/article/details/131727381
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。