当前位置: 代码迷 >> 综合 >> 深入浅出 TiDB 框架
  详细解决方案

深入浅出 TiDB 框架

热度:50   发布时间:2023-12-13 15:23:21.0

-     前言    -


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


-     整体框架    -

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


一个完整的TiDB集群框架如下图:

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,也就不用担心某台机器挂掉。

下图为数据的存储流程。


经过前面的理解,可以将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。


如图:


小结: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)对外提供统一得结束地址。


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官方文档

作者:引渡

来源:

blog.csdn.net/yye894817571/article/details/89394355