TiDB架构原理

TiDB是PingCAP公司自主设计、研发的开源分布式关系型数据库,是一款同时支持OLTP和OLAP业务的融合型分布式数据库产品,具备水平扩容或者缩容、金融级高可用、实时HTAP、云原生的分布式数据库、同时兼容MySQL 5.7协议和MySQL生态等重要特性。
TiDB架构原理
TiDB架构原理
TiDB核心功能组件包括:
1. 计算层TiDB Server,负责与客户端通信,执行SQL解析和优化 。
2. 存储层TiKV和TiFlash,支持key-value键值对存储和列式存储 。
3. 调度层PDCluster,整个集群的大脑,负责分发调度指令给TiKV 。
4. 分析计算模块TiSPARK,与Spark集群进行联动 。
5. 云原生架构,基于K8S实现容器云平台的自动化部署和运维 。
6. 通过TiDB Binlog实现MySQL数据库的实时同步 。
TiDB架构原理
TiDB执行流程:
1. 用户的SQL请求会直接或者通过 Load Balancer发送到TiDB Server 。
2. TiDB Server会解析MySQL Protocol Packet,获取请求内容,对SQL进行语法解析和语义分析,制定和优化查询计划,执行查询计划并获取和处理数据 。
3. PD server根据TiKV节点实时上报的数据分布状态,下发数据调度命令给具体的TiKV节点 。
4. 数据全部存储在TiKV集群中, TiKV根据SQL请求返回数据到TiDB Server 。
5. 最后TiDB Server需要将查询结果返回给用户。

TiDB 核心功能组件解析

1、TiDB Server
TiDB Server是SQL层,对外暴露MySQL协议的连接endpoint,负责接受客户端的连接,执行 SQL 解析和优化,最终生成分布式执行计划。TiDB层本身是无状态的,TiDB Server本身并不存储数据,只是解析 SQL,将实际的数据读取请求翻译成key-value操作转发给底层的存储节点 TiKV(或 TiFlash),最终查询结果返回给客户端。

SQL层架构如下所示:
TiDB架构原理
用户的SQL请求会直接或者通过 Load Balancer发送到TiDB Server,TiDB Server会解析MySQL Protocol Packet,获取请求内容,对SQL进行语法解析和语义分析,制定和优化查询计划,执行查询计划并获取和处理数据。数据全部存储在TiKV集群中,所以在这个过程中TiDB Server需要和TiKV交互,获取数据。最后 TiDB Server需要将查询结果返回给用户。

2、 PD Server
PD server是整个TiDB集群的元信息管理模块,负责存储每个TiKV节点实时的数据分布情况和集群的整体拓扑结构,提供TiDB Dashboard管控界面,并为分布式事务分配事务 ID。PD不仅存储元信息,同时还会根据TiKV节点实时上报的数据分布状态,下发数据调度命令给具体的TiKV节点,可以说是整个集群的“大脑”。
TiDB架构原理

调度信息的收集
调度依赖于整个集群信息的收集,简单来说,调度需要知道每个TiKV节点的状态以及每个 Region的状态。

TiKV集群会以心跳包的形式定期向PD汇报两类消息,TiKV节点信息和Region信息:
1. 每个TiKV节点会定期向PD汇报节点的状态信息,包括磁盘容量、承载的Region数量、数据写入/读取速度、发送/接收的Snapshot数量、是否过载等。
2. 每个Raft group leader会定期向PD汇报Region状态信息,包括Leader的位置、Followers的位置、掉线Replica的数量、数据写入/读取速度等。

调度的策略
PD在收集到信息后,会根据一些调度策略来制定具体的调度计划:

1. Region中副本的数量,当发现副本数量不满足Raft算法要求时,需要通过ADD或Remove副本来调整副本数量。
2. Raft Group中多个副本不在同一个位置,一般情况下PD只会保证多个副本不会落在同一个节点上,以避免单个副本失效导致多个副本丢失。
3. 副本在存储之间均匀分配,使得各节点之间承载的数据更均衡。
4. Leader数量在存储之间均匀分配,Raft协议要求读写都是在leader上完成,因此PD会尽量保证leader在节点之间分散开。
5.访问热点数据在存储间均匀分配,PD会检测出访问热点,并将其在节点之间分散开。
6. 各个存储的空间使用大致相等,PD在调度时候会考虑节点的存储空间剩余量。
7. 控制调度速度,避免影响在线服务,调度操作需要耗费CPU、内存、磁盘IO以及网络带宽,PD会对当前正在进行的操作数量进行控制。

3、 TiKV存储
TiKV负责存储数据,从外部看TiKV是一个分布式的提供事务的Key-Value存储引擎。存储数据的基本单位是Region,每个Region负责存储一个Key Range(从 StartKey 到 EndKey 的左闭右开区间)的数据,每个TiKV节点会负责多个Region。TiKV的API在KV键值对层面提供对分布式事务的原生支持,默认提供了SI (Snapshot Isolation)的隔离级别,这也是TiDB在SQL层面支持分布式事务的核心。TiDB的SQL层做完SQL解析后,会将SQL的执行计划转换为对TiKV API的实际调用。
TiDB架构原理

Key-value键值对
TiDB采用Key-Value模型存储数据,key-value键值对是一个巨大的map,这个map会按照key的二进制顺序有序排列。

存储引擎RocksDB
TiDB没有直接向磁盘上写数据,而是把数据保存在RocksDB中,具体的数据落地由RocksDB负责。RocksDB 是由Facebook开源的一个非常优秀的单机KV存储引擎,可以满足TiKV对单机引擎的各种要求。这里可以简单的认为RocksDB是一个单机的持久化Key-Value Map。

Region
TiKV将整个key-value空间分成很多段,每一段是连续的key,这些段称为region,目前TiKV中默认Region大小是96MB。TiKV会以region为单位,将数据分散在集群的所有节点上,并且保证每个节点上服务的Region数量差不多,并且以Region为单位做Raft的复制和成员管理。
这样做有以下好处:
1. TiDB中的PD调度系统会将Region数据尽可能的分布在不同的节点上,可以实现存储数据的水平扩展和负载均衡。同时PD也会记录Region在节点中的分布情况,也就是通过任意一个key就可以查到这个key在哪个region上。
2. TiKV以Region为单位做数据的复制,这样一个Region的数据会保存多个副本,副本之间通过Raft来保证数据的一致性。一个Region的多个副本会保存在不同的节点上,构成一个Raft Group。其中一个副本会作为这个Group的Leader,其他的副本作为Follower。默认情况下,所有的读和写都是通过Leader进行,读操作在Leader上即可完成,而写操作再由Leader复制给Follower。

多版本控制MVCC
TiKV的MVCC是通过在key后面添加版本号实现的,没有MVCC之前,可以把TiKV看做这样的:

Key1 -> Value
Key2 -> Value
……
KeyN -> Value

有了MVCC之后,TiKV的Key排列是这样的:

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
……

相关新闻

联系我们

全国服务热线

400-033-9553

电子邮件:admin@example.com
工作时间:09:00-17:00 周一至周五

在线客服
关注微信
关注微信
分享本页
返回顶部