TiDB的分布式事务原理探究

事务开启

---

获取全局授时作为startTS构建一个tikvTxn对象（包括snapshot）。

事务写

---

txn.Set方法本质上将kv值写入了一个内存缓存(即kv/memdb_buffer.go中的memDbBuffer)中。该内存kv数据库利用的是golevel提供的功能。

事务回滚

---

直接将tikvTxn的valid字段置为false，之后如果用户再执行提交或者回滚操作，会检查valid，如果为false则直接返回错误。

事务提交

---

操作映射

遍历kv数据库中所有的key，并将每个key和其操作组装到一起成为一个mutationEx对象，并且将其放到一个map中（map由key映射到mutationEx），最后将这个map放入twoPhaseCommitter的mutations字段。

操作也是通过key的内容推断出来的，推断逻辑如下：

• key的长度为0，则操作为删除（Op_Del）
• 如果key的长度大于0，且不需要延迟检查或者延迟检查不通过（value的当前长度大于0），则操作为Op_Put（即新增key或者更新key）
• 如果key的长度大于0，且延迟检查(value的当前长度等于0)通过，则操作为Op_Insert（即新增key，不允许更新key）
• 对于tikvTxn中的lockKeys字段中的key，如果他在kv数据库中不存在的话，则给予Op_Lock（即单纯的作为锁，事务结束就将这个key删除）

Prewrite

Percolator事务模型有primary和secondaries的概念，TiDB的实现中直接将第一个key作为Primary，剩下的Key全部作为secondaries

TiDB上的操作：

• 将所有的key按照Region进行分组（从Region缓存或者PD中获取key所处的Region）
• 将每组的key再拆分成Batch（每个Batch在16k作为，主要目的是为了缩小RPC packet的大小），并发地对每个batch进行处理（即给TiKV发送Prewrite指令）

注意：其实在Prewrite阶段的实现并不太能看出primary和secondaries的区别，他们都被一起打成batch并发处理了。

Tikv接收到指令之后对每个Batch分别进行Prewrite：

遍历batch中每个元素的mutationEx（之前操作映射时组装的），然后分别进行如下操作：

• 如果操作是Op_Insert的话，则以事务开始时间startTs进行快照读检查key是否重复，如果重复则标记错误，看batch中下一个元素
• 编码出一把锁（所谓“锁”就是指key的version为全0的64位bit，正常情况下是时间戳，所以锁永远排在第一个）
• 检查是否有其他事务给该key上锁（即查看是否有version为全0的key），如果有则事务冲突
• 上面的检查通过了的话，则查看Rocksdb上紧接着锁的下一个key（即最新的key），查看其时间戳是否大于等于startTs，如果这样的话，说明有其他事务先提交了，事务冲突。
• 上面的检查也通过了的话则将自己的锁（"锁"的信息包括startTs，primary，value以及操作码等等，详见store/mockstore/mocktikv/mvcc.go中的mvccLock结构）插入进去

Commit

TiDB中的逻辑：

• 重新获得一个全局授时作为提交时间戳commitTs
• Region分组，Batch拆分和上面是一样的
• 先提交Primary
• 然后在后台提交secondaries

TiKV中的逻辑：

新建一个Rocksdb的Batch进行批量的增删，然后对于每个key

• 除了Op_Lock操作的Key，都以CommitTS作为Key的版本号插入进去，组装Value的时候将TiKV的操作码转成底层mvcc store的操作码（将Op_put转成typePut，剩下的除了不可能出现的Op_Lock，都转换成typeDelete），然后删除锁
• 对于Op_Lock操作的Key则直接删除锁即可

End

---

作者：元青

微信公众号 「技乐书香」