Day 6 - TiKV架构

TiKV Server是负责保存数据资料，采key-value模式储存，且key的排列是二进制有序的。这部分TiDB是采用RockDB来控制，RockDB是Facebook以Google的levelDB为基础再开发的一套key-value储存引擎。这部分交给专业的来，所以TiDB就没有另外再自行开发一套。

另外TiKV透过了实作Raft协议让资料产生副本，分散在每一个Tikv node上，副本通常是3份。资料会先写入raft log中，然後透过协议同步复制到其他node上，然後再写入rockDB，最终透过RockDB的机制flush到disk中。这样一个node挂了还有其他node可以使用。

引用pingcap官网架构图

前面提到key的排列是有序的，而TiKV会依据设定的大小将key-value切成一小段，每一段称为Region，每一段的范围是[Key1，Keyn)，即包括Key1到Keyn之间不包括keyn。
如图所示 资料会被切成大小相近的四份(R1~R4)。而这四个Region会被平均分布到三个node上，如下图node1有R1与R2，而node2中有R3，node3则有R4。这部分是PD Server做的调度，我们放到後面介绍PD的时候再解释。

以上图为例，node1与node2都有R3，则是我们前面提到的副本也被称作replica，是以Region为单位做副本机制。而全部的R3统称为一个Raft group。一个Raft group里头会有一个leader与多个follower，预设所有读跟写的操作都会透过leader，写的部分会先写入leader然後复制到follower，读的部分就只要在leader读。
有没有发现这样的机制可能会造成的问题？瓶颈有可能会卡在leader身上，所以目前的版本有支援新的功能Follower Read，藉以分散leader的loading。

除此之外TiKV还可以透过Coprocessor为TiDB分担部分的计算，也就是前面讨论TiDB架构的时候提到的物理优化计划的执行者。