TiKV 是如何存储数据的（下）

RawKV

TiKV 提供两套 API，一套叫做 RawKV，另一套叫做 TxnKV。TxnKV 对应的就是上篇文章中提到的 Percolator，而 RawKV 则不会对事务做任何保证，而且比 TxnKV 简单很多，这里我们先讨论 RawKV。

Write

当进行写入，譬如 Write a = 1，会进行如下步骤：

1. Client 找 PD 问 a 所在的 Region

2. PD 告诉 Region 相关信息，主要是 Leader 所在的 TiKV

3. Client 将命令发送给 Leader 所在的 TiKV

4. Leader 接受请求之后执行 Raft 流程

5. Leader 将 a = 1 Apply 到 KV RocksDB 然后给 Client 返回写入成功

Read

对于 Read 来说，也是一样的操作，唯一不同在于 Leader 可以直接提供 Read，不需要走 Raft。

TxnKV

Write

对于 TxnKV 来说，情况就要复杂的多，不过大部分流程已经在 Percolator 章节进行说明了。这里需要注意的是，因为我们要快速的 seek 到最新的 commit，所以在 RocksDB 里面，我们会先将 TS 使用 bigendian 生成 8 字节的 bytes，然后将这个 bytes 逐位取反，在跟原始的 key 组合存储到 RocksDB 里面，这样就能保证最新的提交存放到前面，seek 的时候就能直接定位了，当然 seek 的时候，也同样会将对应的 TS 按照相同的方式编码处理。

譬如，假设一个 key 现在有两次提交，commitTS 分别为 10 和 12，startTS 则是 9 和 11，那么在 RocksDB 里面，key 的存放顺序则是：

另外，还需要注意的是，对于 value 比较小的情况，TiKV 会直接将 value 存放到 Write CF 里面，这样 Read 的时候只要走 Write CF 就行了。在写入的时候，流程如下：

对于 TiKV 来说，在 Commit 阶段无论怎样都会读取 Lock 来判断事务冲突，所以我们可以从 Lock 拿到数据，然后再写入到 Write CF 里面。

Read

Read 的流程之前的 Percolator 已经有说明了，这里就不详细解释了。

SQL Key Mapping

我们在 TiKV 上面构建了一个分布式数据库 TiDB，它是一个关系型数据库，所以大家需要关注的是一个关系型的 table 是如何映射到 key-value 上面的。假设我们有如下的表结构：

上面我们创建了一张表 t1，里面有四个字段，id 是主键，name 是唯一索引，age 是一个索引。那么这个表里面的数据是如何对应到 TiKV 的呢？

在 TiDB 里面，任何一张表都有一个唯一的 ID，譬如这里是 11，任何的索引也有唯一的 ID，上面 name 就是 12，age 就是 13。我们使用前缀 t 和 i 来区分表里面的 data 和 index。对于上面表 t1 来说，假设现在它有两行数据，分别是 (1, “a”, 10, “hello”) 和 (2, “b”, 12, “world”)，在 TiKV 里面，每一行数据会有不同的 key-value 对应。如下：

因为 PK 具有唯一性，所以我们可以用 t + Table ID + PK 来唯一表示一行数据，value 就是这行数据。对于 Unique 来说，也是具有唯一性的，所以我们用 i + Index ID + name 来表示，而 value 则是对应的 PK。如果两个 name 相同，就会破坏唯一性约束。当我们使用 Unique 来查询的时候，会先找到对应的 PK，然后再通过 PK 找到对应的数据。

对于普通的 Index 来说，不需要唯一性约束，所以我们使用 i + Index ID + age + PK，而 value 为空。因为 PK 一定是唯一的，所以两行数据即使 age 一样，也不会冲突。当我们使用 Index 来查询的时候，会先 seek 到第一个大于等于 i + Index ID + age 这个 key 的数据，然后看前缀是否匹配，如果匹配，则解码出对应的 PK，再从 PK 拿到实际的数据。

TiDB 在操作 TiKV 的时候需要保证操作 keys 的一致性，所以需要使用 TxnKV 模式。

结语

延展阅读