TiDB架构_TiDB

TiDB Server

对外暴露 MySQL 协议,负责 SQL 的解析、优化,并最终生成分布式执行计划,MySQL 的 Server 层也会涉及到 SQL 的解析、优化,但与 MySQL 最大的不同在于,TiDB Server 是无状态的。

TiDB Server 只干一件事:负责解析 SQL,将实际的数据操作转发给存储节点。

生产中可以启动多个实例,并通过负载均衡的策略来对外提供统一服务。


TiKV

TiDB 的存储是由 TiKV 来负责的,这是一个分布式、支持事务的 KV 存储引擎。

TiKV 在存储数据时,会将同一份数据想办法存储到多个 TiKV 节点上,并且使用 Raft 协议来保证同一份数据在多个 TiKV 节点上的数据一致性。


region

从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region,每个 Region 负责存储一个

Key Range(从 StartKey 到 EndKey 的左闭右开区间)的数据,每个 TiKV 节点会负责多个 Region。


PD

TiDB Server 解析了之后,它是怎么知道自己要找的数据在哪个 Region 里?这个 Region 又在哪个 TiKV 上? PD充当一个元数据信息存储的角色。

另外也是整个集群的控制节点。

PD 会让任何时候集群内的 Raft Group 副本数量保持预期值。热点 Region 的情况,并不是所有的 Region 都会被频繁的访问到,PD 就需要对这些热点 Region 进行负载均衡的调度。如果Leader Replica 挂了,PD 会从 Raft Group 的 Replica 中选举出一个新的 Leader。

PD 而要做到调度这些决策,必然需要掌控整个集群的相关数据,比如现在有多少个 TiKV?多少个 Raft Group?每个 Raft Group 的 Leader 在哪里等等,这些其实都是通过心跳机制来收集的。PD 通过心跳来收集数据,更新维护整个集群的元数据,并且在心跳返回时,将对应的「调度指令」返回。