摘要：对于上面表来说，假设现在它有两行数据，分别是和，在里面，每一行数据会有不同的对应。对于来说，也是具有唯一性的，所以我们用来表示，而则是对应的。如果两个相同，就会破坏唯一性约束。因为一定是唯一的，所以两行数据即使一样，也不会冲突。
上篇文章中，我们介绍了与 TiKV 处理读写请求相关的基础知识，下面将开始详细的介绍 TiKV 的读写流程。Enjoy~
作者：唐刘 @siddontang
RawKVTiKV 提供两套 API，一套叫做 RawKV，另一套叫做 TxnKV。TxnKV 对应的就是上面提到的 Percolator，而 RawKV 则不会对事务做任何保证，而且比 TxnKV 简单很多，这里我们先讨论 RawKV。
Write当进行写入，譬如 Write a = 1，会进行如下步骤：
Client 找 PD 问 a 所在的 Region
PD 告诉 Region 相关信息，主要是 Leader 所在的 TiKV
Client 将命令发送给 Leader 所在的 TiKV
Leader 接受请求之后执行 Raft 流程
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 的存放顺序则是：
Write CF： a_12 -> 11 a_10 -> 9 Data CF: a_11 -> data_11 a_9 -> data_9
另外，还需要注意的是，对于 value 比较小的情况，TiKV 会直接将 value 存放到 Write CF 里面，这样 Read 的时候只要走 Write CF 就行了。在写入的时候，流程如下：
PreWrite： Lock CF: W a -> Lock + Data Commit: Lock CF: R a -> Lock + 10 + Data Lock CF: D a Write CF: W a_11 -> 10 + Data
对于 TiKV 来说，在 Commit 阶段无论怎样都会读取 Lock 来判断事务冲突，所以我们可以从 Lock 拿到数据，然后再写入到 Write CF 里面。
ReadRead 的流程之前的 Percolator 已经有说明了，这里就不详细解释了。
SQL Key Mapping我们在 TiKV 上面构建了一个分布式数据库 TiDB，它是一个关系型数据库，所以大家需要关注的是一个关系型的 table 是如何映射到 key-value 上面的。假设我们有如下的表结构：
CREATE TABLE t1 {
id BIGINT PRIMARY KEY,
name VARCHAR(1024),
age BIGINT,
content BLOB,
UNIQUE(name),
INDEX(age),
}
上面我们创建了一张表 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_11_1 -> (1, “a”, 10, “hello”) t_11_2 -> (2, “b”, 12, “world”) Unique Name i_12_a -> 1 i_12_b -> 2 Index Age i_13_10_1 -> nil i_13_12_2 -> nil
因为 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 模式。
结语上面简单的介绍了下 TiKV 读写数据的流程，还有很多东西并没有覆盖到，譬如错误处理，Percolator 的性能优化这些，如果你对这些感兴趣，可以参与到 TiKV 的开发，欢迎联系我 tl@pingcap.com。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/62580.html
摘要：对于上面表来说，假设现在它有两行数据，分别是和，在里面，每一行数据会有不同的对应。对于来说，也是具有唯一性的，所以我们用来表示，而则是对应的。如果两个相同，就会破坏唯一性约束。因为一定是唯一的，所以两行数据即使一样，也不会冲突。 上篇文章中，我们介绍了与 TiKV 处理读写请求相关的基础知识，下面将开始详细的介绍 TiKV 的读写流程。Enjoy~ 作者：唐刘 @siddontang...
摘要：作者唐刘本文会详细的介绍是如何处理读写请求的，通过该文档，同学们会知道是如何将一个写请求包含的数据更改存储到系统，并且能读出对应的数据的。每个包含两个实例，一个用于存储，我们后面称为，而另一个则是存放用户实际的数据，我们称为。 作者：唐刘 siddontang 本文会详细的介绍 TiKV 是如何处理读写请求的，通过该文档，同学们会知道 TiKV 是如何将一个写请求包含的数据更改存储到系...
摘要：作者唐刘本文会详细的介绍是如何处理读写请求的，通过该文档，同学们会知道是如何将一个写请求包含的数据更改存储到系统，并且能读出对应的数据的。每个包含两个实例，一个用于存储，我们后面称为，而另一个则是存放用户实际的数据，我们称为。 作者：唐刘 siddontang 本文会详细的介绍 TiKV 是如何处理读写请求的，通过该文档，同学们会知道 TiKV 是如何将一个写请求包含的数据更改存储到系...
摘要：本文为源码阅读系列文章的第二篇，第一篇文章介绍了整体的架构，知道有哪些模块，分别是做什么的，从哪里入手比较好，哪些可以忽略，哪些需要仔细阅读。具体的实现是按照协议实现，具体的协议可以参考协议文档。 本文为 TiDB 源码阅读系列文章的第二篇，第一篇文章介绍了 TiDB 整体的架构，知道 TiDB 有哪些模块，分别是做什么的，从哪里入手比较好，哪些可以忽略，哪些需要仔细阅读。 这篇文章是...
摘要：本文为源码阅读系列文章的第二篇，第一篇文章介绍了整体的架构，知道有哪些模块，分别是做什么的，从哪里入手比较好，哪些可以忽略，哪些需要仔细阅读。具体的实现是按照协议实现，具体的协议可以参考协议文档。 本文为 TiDB 源码阅读系列文章的第二篇，第一篇文章介绍了 TiDB 整体的架构，知道 TiDB 有哪些模块，分别是做什么的，从哪里入手比较好，哪些可以忽略，哪些需要仔细阅读。 这篇文章是...
阅读 1832·2021-11-25 09:43
阅读 462·2021-10-11 10:58
阅读 1507·2019-08-30 15:55
阅读 1614·2019-08-30 13:13
阅读 623·2019-08-29 17:01
阅读 1727·2019-08-29 15:30
阅读 653·2019-08-29 13:49
阅读 2045·2019-08-29 12:13
