Tikv事务学习笔记

Tikv是一个分布式key-value存储系统，由PingCap公司开发，最初是用于支持Tidb。项目地址以及简介可以参考:

tikv
说存储

Tikv的分布式事务处理沿用了Google的Percolator模型，简单的说，Percolator是一个构建在bigtable之上的二阶段提交模型。Percolator的原始论文以及相关解读可以参考：

原文地址
Percolator 和 TiDB 事务算法
Google Percolator 分布式事务实现原理解读

一个简化的流程图如下：

percolator.png

Tidb中的实现

percolator是在bigtable之上实现的，通过client库来调用bigtable的读写接口，实现分布式事务。对应到Tikv中，由上层的Tidb和Tikv一起协作完成分布式事务处理。按照两阶段提交协议来说，Tidb是TM(Transaction Manager)，Tikv是RM(Resource Manager)。

tidb中把底层kv存储抽象为一系列interface，定义在kv/kv.go中。其中最主要的一个接口是Storage，调用Driver.Open()即返回一个Storage类型的实例，然后Storage.Begin()返回一个事务，事务的类型也由接口描述。使用抽象的interface的好处是，可以在底层使用不同的kv存储介质。实现和tikv交互的Storage类型是tikvStore，定义在store/tikv/kv.go中，相应的事务类型就是tikvTxn。

tikvTxn结构

newTikvTxn返回一个tikvTxn实例，它首先从PD获得一个时间戳，记为事务的startTS，然后以startTS初始化tikvTxn结构。其中主要是初始化unionStore成员，代码注释中说明了这个结构的作用：

unionStore is an in-memory Store which contains a buffer for write and a snapshot for read.

缓存用于更新数据，也就是所有的写操作都会先在本地缓存。快照用于读取数据，这个快照本质上就是记录了一个时间戳，即startTS。在使用tikvTxn读取数据时，只会读取到版本小于startTS的数据。检测索引冲突的时候，也是以startTS版本的数据为准。到commit时，如果tikv检测到有其他事务已经写入了大于startTS版本的数据，则commit失败。

对事务中的所有更新操作，按照如下逻辑处理：

基于startTS版本的数据进行冲突检查
将更新操作写入缓存

完成这两步后，调用tikvTxn.Commit方法开始两阶段提交，实现代码在文件store/tikv/2pc.go中。主要的逻辑是调用prewriteSingleBatch和commitSingleBatch，这两个都是发送到tikv的rpc请求，调用的逻辑使用了一个指数回退的重试策略

可以把Tidb中和Tikv交互这部分代码单独拎出来，在自己的应用程序中实现分布式事务。PingCap提供了使用Tikv的事务API的示例，地址在此

Tikv的实现

多版本

数据是有版本的，这一点是必须的，否则无法支持percolator模型。在prewrite的处理过程中，就已经将带版本的数据写入了，commit只是设置数据最新的版本号。具体来说，Tikv为每个key的数据都写入了三条数据，分别在三个不同的列族中(rocksdb支持column family)。

CF_DEFAULT 实际数据value, key是带版本的
CF_WRITE 记录当前最新数据的版本，如果数据很短，可能直接写在这一列
CF_LOCK 锁数据

CF.jpg

请求调度

tikv是个多线程运行的模型，对读和写请求的处理在不同的线程中完成。对于写请求，都需要经过一个Scheduler模块的调度，Scheduler的功能在代码注释中描述了：

//! Scheduler keeps track of all the running commands and uses latches to ensure serialized access
//! to the overlapping rows involved in concurrent commands. But note that scheduler only ensures
//! serialized access to the overlapping rows at command level, but a transaction may consist of
//! multiple commands, therefore conflicts may happen at transaction level. Transaction semantics
//! is ensured by the transaction protocol implemented in the client library, which is transparent
//! to the scheduler.

简单的说，这个模块的作用是保证对相同数据的串行访问。要在单机上实现类似于bigtable的单行事务，必须要有这一层。

prewrite和commit

prewrite和commit的实现在storage/mvcc/txn.rs中，这两步的逻辑和percolator中描述的基本相同。

对每个key的都进行prewrite，prewrite过程：

检查在startTS后，有没有新的数据写入到CF_WRITE列。如果有，则发生冲突，prewrite失败
检查在CF_LOCK列有没有锁数据，如果有，则发生冲突，prewrite失败
写入CF_LOCK列，内容是start_ts + lock_type + primary_key + lock_ttl，如果value的长度小于64字节，也写入到CF_LOCK。如果大于64，则以key+startTS为key将value写入到CF_DEFAULT中。

这里的primary key是tidb选择的，作为请求参数传递给tikv。

如果prewrite返回成功，接下来tidb就会发起commit请求。tikv对commit的处理：对每个key，检查锁的状态，如果锁存在并且lock.ts == startTS，则写入CF_WRITE列，key是key+commitTS，内容是startTs+type。

回滚这块的逻辑还没看太明白。待补充
写入类型中，除了Put Delete之外，还有个一LOCK类型，还没看出是什么作用。待补充

get

读取实现在storage/mvcc/reader/mod.rs中。默认的隔离级别是SI，首先是检查CF_LOCK列的锁数据：

如果没有锁数据，则可以直接读取数据
如果存在锁，但是锁的ts大于此次读取请求中的版本，就是在发起读请求之后加上的锁，可以直接读取数据
如果存在锁，并且锁的ts在此次读取版本之前，则get失败。

如果锁是ok的，就从CF_WRITE列中读出startTS，然后以key+startTS为key读取CF_DEFAULT中的数据。

数据GC

因为使用了MVCC，旧的版本需要清理。数据gc的机制是从tidb发送一个gc请求给tikv，请求参数中包含了一个safePoint，也就是说在这个safePoint版本之前的数据，都可以安全的删除掉。

tidb是如何跟踪和确认safePoint这一部分还没有看太明白。待补充