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 锁

    - 分布式事务:其他⾏看主锁补数据,主锁宕机则事务回滚