TIDB的分布式事物
1.分布式事物的写入逻辑
Begin ..commit
1.⾸先从pd获取⼀个开始时间戳,startts
2.将需要修改数据放⼊内存中,进⾏修改
3.事务commit,进⼊两阶段提交
第⼀阶段:prewrite:将修改数据和锁信息写⼊到tikv节点中中
- 写⼊列簇中存储数据
- Deafault cf: 3_timestamp,修改数据
- lock cf:给⼀个事务的第⼀⾏加⼀个主锁(3 id,W 写锁,pk主锁,100 timestamp等信息),其他⾏指向主锁加secondary lock, 其他事务不能占⽤此事务lock的⾏
- 乐观事务:begin和commit之间其他事务⽆法感知,只有commit时候才能感知
- 悲观事务:在begin后写⼊Lock,提前占⽤.(之后事务在讲解)
第⼆阶段:commit
- 去PD组件找timestamp作为commit timestamp
- commit写⼊:在write cf中写⼊commit信息(3_commitstamp,startts)
- Lock清理:W-->D (3,(D,pk)),删除锁
- 清空Lock,数据修改完毕
- 其他事务读取可以看到Wrtie cf找到最近⼀次startts时间,获得 3_100,去Default寻找到值Frank
2. TiKV分布式事务多节点写⼊
场景:
1写⼊tikv node1 , 2写⼊tikv node2
1.事务开始获得 starts
2.数据到tidb-server内存中修改
3.事务提交commit
4.Prewrite阶段,将修改两⾏数据和lock分别写⼊两个tikv的 cf中
- default (1_startts,Jack),default (2_startts,Candy)
- lock (1,W,pk 主锁,1 修改第⼀⾏,100。。。) (2_100,W,@1 指向主锁,2 修改第⼆⾏,100...)
5.commit阶段
- 获得endts
- 写⼊wrtie(1_endts,startts) wrtie(2_endts,startts)
- lock标记(加⼊⼀⾏ Delete锁 标记)
- 提交commit,清理lock
注:其他会话去读只要读到lock,看到副锁找主锁,发现在修改,W,得知有事务在修改事务。从write找到最近的startts, 去Default读值
6.假设commit时候,tikv node2宕机,即lock信息
在node2没写(delete W +write cf)
- 根据 W @1-->找到 D,pk,1 主锁发现事务已经提交
- node2 lock +write补上数据和 delete 锁
- 分布式事务:其他⾏看主锁补数据,主锁宕机则事务回滚