TiDB存储之TiKV

TiDB是一个开源的分布式NewSQL数据库，设计的目标是满足100%的OLTP和80%的OLAP，支持SQL、水平弹性扩展、分布式事务、跨数据中心数据强一致性保证、故障自恢复的高可用、海量数据高并发实时写入与实时查询。TiDB 集群主要分为三个组件：TiDB Server、PD Server和TiKV Server。
TiKV Server
储存组件TiKV，从名字就能够猜的出来，该组件储存方式应该是以K-V模式储存的。事实上TiKV 选择的是 Key-Value 模型，并且提供有序遍历方法，简单来讲，可以将 TiKV 看做一个巨大的 Map，其中 Key 和 Value 都是原始的 Byte 数组，在这个 Map 中，Key 按照 Byte 数组总的原始二进制比特位比较顺序排列。 整个Key-Value空间分成很多段，每一段是一系列连续的key，每一段叫做一个Region，每个Region保存的数据默认64MB。每一个Region可以用StartKey和EndKey这样一个左开右闭区间来描述，作为一个分布式的具有一定容灾能力的KeyValue系统，TiKV是以Region为单位做数据的复制，一个Region在一个节点上只会有一份，但会有多个副本在其它节点上，一般情况下数据会保存在3个节点。

raft-region.png

既然是 Key-Value模式，那我们就可以看出这样：
Key1 -> Value
Key2 -> Value
……
KeyN -> Value
但是作为一个数据，没有多版本控制（MVCC），那就需要上锁了，在分布式的场景下，可能会带来性能以及死锁的问题。TiKV的MVCC实现是通过在Key后面添加Version来实现的，有了MVCC后的TiKV，可以看成这样：
Key1-Version3 -> Value
Key1-Version2 -> Value
Key1-Version1 -> Value
……
Key2-Version4 -> Value
Key2-Version3 -> Value
Key2-Version2 -> Value
Key2-Version1 -> Value
……
KeyN-Version2 -> Value
KeyN-Version1 -> Value
……
作为数据库，数据最终还是要保存到磁盘上的，TiKV也不例外。但是 TiKV 没有选择直接向磁盘上写数据，而是把数据保存在 RocksDB 中，具体的数据落地由 RocksDB 负责。RocksDB是一个开源的单机存储引擎，Facebook的团队在做持续的优化。数据的复制是有Raft来做的，每个数据变更都会落地为一条 Raft 日志，通过 Raft 的日志复制功能，将数据安全可靠地同步到 Group 的多数节点中。

image.png