国产最强开源 API 数据库，没有之一，不接受任何反驳！

谁践踏了优雅 2022-08-28 02:58 266阅读 0赞

> 开发者（KaiFaX）  
> 
> 
> **面向全栈工程师的开发者**  
>  专注于前端、Java/Python/Go/PHP的技术社区

来源：blog.csdn.net/yye894817571/article/details/89394355

*  前言
 *  整体框架
 *  TiKV Server
 *  PD Server
 *  信息收集
 *  调度的策略
 *  TiDB Server
 *  TiSpark
 *  总结

--------------------

## 前言 ##

经过这几天的学习理解，对TiDB数据库有了一定理解，所以现在回来总结。

## 整体框架 ##

TiDB主要分为3个核心组件：TiDB Server ,PD Server 和TiKV Server，还有用于解决用户复杂OLAP需求的TiSpark组件。部署一个单机版的TiDB，这三个组件都需要启动。如果用生产环境，需要使用Ansible部署TiDB集群。  
一个完整的TiDB集群框架如下图：

![bae439ade5f92d60f99a05dd063d692c.png][]

## TiKV Server ##

TiKV Server 负责存储数据，对于数据存储需要保证实现以下功能：

*  支持跨数据中心的容灾；
 *  写入速度足够快；
 *  读取速度方便；
 *  支持数据修改与并发修改数据；
 *  多条记录修改后保证原子性。

TiKV采用Key-Value模型存储数据，并且提供有序遍历方法。TiKV是一个巨大的Map，TiKV存储的是key-value pair，key-value pair按照key的二进制顺序有序，查找到某个key的位置，可以不断地调用Next方法以递增的顺序获取比这个key大的key-value。  
TiKV的存储模型与SQL中Table无关，TiKV就是一个高性能高可靠性的巨大的（分布式）的map。  
TiKV通过RocksDB将数据持久化到磁盘上，而不是直接向磁盘上写数据，也就是说具体的数据落地是用RocksDB负责。RokcsDB 是一个高性能的单机引擎，有FaceBook的团队做持续优化。  
如果要做到数据不丢失，支持跨数据中心的容灾，就需要将数据负责到多台机器上，但是这个时候就涉及到数据一致性的问题了。TiDB采用Raft协议来保证数据一致性，Raft是一个一致性算法，PingCAP公司对Raft协议的实现做了大量的优化来保证这一协议切实可行。  
Raft是一个一致性协议，提供了以下几个重要的功能：

*  Leader选举；
 *  成员变更；
 *  日志复制；

TiKV利用Raft来做数据复制，每个数据变更都会落地为一条Raft日志，通过Raft的日志复制功能，将数据安全可靠地同步到Group的多数节点中，以防单机失效。数据的写入是通过Raft这一层的接口写入，而不是直接写RocksDB。通过Raft实现，我们拥有一个分布式的巨大Map，也就不用担心某台机器挂掉。  
下图为数据的存储流程。  
![27bc3b983ba1163381be5abaddcf72bb.png][]

经过前面的理解，可以将TiKV看作是一个kv系统，TiKV是以Region为单位做存储与复制，将key-value分段存储在节点上，每一段是一系列连续的key,也就是分Range，每一段就是一个Region。每个Region中存储的数据不超过一定的大小（默认是64mb),每一个Region都可以用StartKey到EndKey这样一个左闭右开区间来描述。  
系统会通过一个组件来负责将Region尽可能均匀的散步在集群中所有的节点上，这样一方面实现了存储容量的水平扩展，另一方面也实现了负载均衡。为了保证上层客户端能够访问所需要的数据，系统会有一个组件记录Region在节点上面的分布情况，可以通过任意一个key就能查询到这个key在哪个Region中，以及这个Region在哪个节点上。  
TiKV以Region为单位做数据的复制，也就是一个Region的数据会保存多个副本，每个副本叫做一个Replica.Replica之间是通过Raft来保证数据的一致性，一个Region的多个Replica会保存在不同的节点上，构成一个Raft Group。其中Replica会作为这个Group的leader，其他的Replica作为Follower。所有的读和写都是通过Leader进行，在由leader复制给Follower。  
如图：

![c4676150c2bd8898535b6fa2a1274cd0.png][]

小结：TiKV是一个分布式key-value存储系统，一个巨大的分布式Map系统，一个全局有序的分布式key-value引擎。

## PD Server ##

Placement Driver（简称PD）是TiDB里面全局中心总控节点，是整个集群的管理模块，负责整个集群的调度。

TiDB作为一个分布式高可用存储系统，系统需要具备多副本容错，动态扩容、缩容，容忍节点掉线以及自动错误恢复的功能，且整个系统负载均与，方便管理。需要满足这些功能，TiDB就需要收集足够的信息，比如每个节点的状态、每个Raft Group的信息，业务访问操作的统计等。PD根据这些信息以及调度的策略，置顶出了尽量满足这些需求的调度计划，并提供基本操作来完成这个计划。

## 信息收集 ##

调度依赖于这个集群信息的收集，PD需要知道每个TiKV节点的状态以及每个Region的状态。TiKV集群会向PD汇报两类信息。

**一、每个TiKV节点会定期向PD汇报节点的整体信息。**

TiKV节点（store)与PD之间存在心跳包，一方面PD通过心跳包检测每个Store是否存活，以及是否有新加入的Store；另一方面也会携带这个Store的状态信息，主要包括：

*  总磁盘容量
 *  可用磁盘容量
 *  承载的Region数量
 *  数据写入速度
 *  发送/接受的Snapshot数量（Replica之间可能会通过Snapshot同步数据）
 *  是否过载
 *  标签信息（标签是具备层级关系的一系列Tag）

**二、每个Raft Group的Leader会定期向PD汇报信息**

每个Raft Group的Leader和PD之间存在心跳包，用于汇报这个Region的状态，主要包括下面几点信息：

*  leader的位置
 *  Followers的位置
 *  掉线Replica的个数
 *  数据写入/读取的速度

PD不断的通过这两类心跳消息收集整个集群的信息，再以这些信息座位决策的依据。除此之外，PD还可以通过管理接口接受额外的信息，用来做更准确的决策。比如当某个Store的心跳包中断的时候，PD并不能判断这个节点是临时失效还是永久失效，只能经过一段时间的等待（默认是30分钟），如果一直没有心跳包，就认为是Store已经下线，再决定需要将这个Store上面的Region都调度走。但是有的时候，是运维人员主动将某台机器下线，这个时候，可以通过PD的管理接口通知PD改Store不可用，PD就可以马上判断判断需要将这个Store上面的Region都调度走。

## 调度的策略 ##

PD收集了这些信息后，还需要一些策略来制定具体的调度计划。

**一、一个Region的Replica数量正确**

当PD通过某个Region Leader的心跳包发现这个Region的Replica数量不满足要求时，需要通过Add/Remove Replica 操作调整Replica数量。

**二、一个Raft Group中的多个Replica不在同一个位置**

**三、副本在Store之间的分布均匀分配**

每个副本中存储的数据容量上限是固定的，所以维持每个节点上面副本数量的均衡，会使得总体负载更均衡。

**四、Leader数量在Store之间均匀分配**

Raft协议要读取和写入都通过Leader进行，所以 计算的负载主要在Leader上面，PD会尽可能讲Leader在节点之间分散。

**五、访问热点数量在Store之间均匀分配**

每个Store以及Region Leader在上报信息是携带了当前访问负载的信息，比如Key的读取/写入速度。PD会检测出访问热点，且将其在节点之间分散。

**六、各个Store的存储空间占用大致相等**

每个Store启动的时候都会指定一个Capacity参数，表明这个Store的存储空间上限，PD在做调度的时候，会考虑节点的存储空间剩余量。

**七、控制调度速度，避免影响在线服务**

调度操作需要耗费CPU、内存、磁盘IO以及网络带宽，我们需要避免对线上服务造成太大影响。PD会对当前正在进行的操作数量进行控制，默认的速度控制是比较保守的，如果希望加快调度（比如已经停服务升级，增加新节点，希望尽快调度），那么可以通过pd-ctl手动加快调度速度。

**八、支持手动下线节点**

当通过pd-ctl手动下线节点后，PD会在一定速率控制下，将节点上的数据调度走。当调度完成后，就会将这个节点置为下线状态。

小结：作为中心中控节点，PD通过集成etcd，自动得支持auto failover，无须担心单点故障问题。同时PD也通过etcd的raft，保证了数据强一致性，不用担心数据丢失问题。除此之外，PD还负责全局ID的生成，以及全局时间戳TSO的生成，保存整个集群TiKV的元信息，负责给client提供路由功能。

## TiDB Server ##

TiDB Server负责接收应用成发送过来的SQL请求，处理SQL相关的逻辑，并通过PD找到存储所需数据的TiKV地址，与TiKV交互获取数据，最终返回结果。TiDB Server是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy或F5）对外提供统一得结束地址。

![0ece73f83adb36d215b8756f2eefcd69.png][] TiDB本身并不存储数据，节点之间完全对等，TiDB Server这一层最重要的工作是处理用户请求，执行SQL运算逻辑。

因为TiKV是一个key-value的存储引擎，需要做到SQL到kv的映射，这里可以去具体了解它的映射方案。

用户的SQL请求会直接或者通过Load Balancer 发送到TiDB-Server，TiDB会解析MySQLProtocol Packet，获取请求内容，然后做语法分析、查询计划指定和优化、执行查询计划获取和处理数据。数据全部存储在TiKV集群中，这个过程中TiDB-server会和TiKV-Server交互，获取数据，最后TiDB-Server需要将查询结果返回给用户。

## TiSpark ##

TiSpark就是Spark SQL on TiKV，是解决用户复杂OLAP需求的主要组件,将Spark SQL 直接运行在TiDB存储层上，同时融合TiKV 分布集群的优势，和 TiDB 一起为用户一站式解决 HTAP （Hybrid Transactional/Analytical Processing）需求。TiSPark依赖于TiKV集群和PD的存在。如果需要用到TiSPark，也需要搭建一个Spark集群。由于目前项目中没有用到TiSPark，在这里就不深入研究。

## 总结 ##

TiKV Server负责存储，PD Server 负责调度，TiDB Server负责计算，三者中间有个至关重要的协议Raft，这个协议保证了TiDB这个分布式数据库的数据安全一致。

参考文档：TiDB官方文档

--------------------

1. 回复“m”可以查看历史记录；

2. 回复“h”或者“帮助”，查看帮助；

开发者已开通多个技术群交流学习，请加若飞微信：1321113940 (暗号k）进开发群学习交流

说明：我们都是开发者。视频或文章来源于网络，如涉及版权或有误，请您与若飞（1321113940）联系，将在第一时间删除或者修改，谢谢！

![0405c5a478015fe5402f3017ecbd81ef.png][]

开 发 者 ： **KaiFaX**

**面向全栈工程师的开发者**  
专注于前端、Java/Python/Go/PHP的技术社区

[bae439ade5f92d60f99a05dd063d692c.png]: /images/20220828/42107ec2409b419e99a89832537a7e9f.png
[27bc3b983ba1163381be5abaddcf72bb.png]: /images/20220828/16627ca451f149148f4090198a114e85.png
[c4676150c2bd8898535b6fa2a1274cd0.png]: /images/20220828/56804ca40be64bd6be568461d8f467c4.png
[0ece73f83adb36d215b8756f2eefcd69.png]: /images/20220828/059db26c3a3d428ea0a3acf3c428a8a6.png
[0405c5a478015fe5402f3017ecbd81ef.png]: /images/20220828/f5bc067dd177426190ec7da07991dc0b.png