【TiDB理论知识06】PD架构与作用

news2024/12/27 10:34:29

一 PD的架构与功能

PD架构

PD作用

名词解释

路由功能

二 TSO的分配

概念

分配过程

性能问题

高可用问题

三 PD的调度原理

总流程

1 信息收集

2 生成调度

3 执行调度

四 Label的作用

Label的配置

给TiKV打标签

PD配置

一 PD的架构与功能

PD架构

PD集群至少由三个节点构成，PD通过集成了etcd支持自动故障转移，PD 通过etcd的raft保障数据的强一致性，所以在生产中建议奇数个。PD中会有leader角色，其实是个单点，只有在发生故障的时候才会发生选举。PD是TiDB数据库的总控，是整个集群的大脑

PD作用

1 元数据的存储，，tidb的执行计划或者SQL语句他怎么知道去哪个Region中找到相应的数据，哪个region存储在哪个TiKV中

2 全局时钟，查询开始，事务开始结束的时间都是由PD授时

3 对Region进行调度，例如某些TiKV的Region较多，产生了热点，需要向其他TiKV进行调度

名词解释

Store :对应TiKV 实例，同一个服务器上部署多个TiKV，则这个服务器上有多个store。

Region：每个Region负责存储集群一段连续的数据默认96M.没份数据会在不同的TIKV存储多个副本，默认是3副本，每个副本叫peer,peer是有角色的，peer也特指raft中的成员

leader :读写都在leader上

follower:

raft Group :通过raft协议构成raft Group

multi Raft: 多个raft组构成multi Raft

以上就是PD需要管理的重要的一些概念

路由功能

路由功能，执行SQL的时候，SQL想要读取的数据所在的Leader Region在哪个TiKV上，是需要问PD的。TiDB server生成执行计划，传到Executor 执行器，然后执行器去执行执行计划，例如此时需要读取key=123，存储在region1 上的数据，TIKV Client 就是会去PD中问，PD 告诉这个Key的位置。

如果每次查询都要去PD中查询region的位置，难免会产生很多的网络开销，网络压力太大了，就会把key=123的位置从PD中取出来，然后缓存在TiKV Client的 Region Cache中。下次再读取就不用从PD中读取。但是这种方法虽然节约了网络开销，但如果key=123数据所在的Region发生了漂移，此时按cache中的位置去读，就会找不到数据，需要重新从PD中取出来，这种现象叫做 Back Off。back off 越多，读取的延迟越多。或者Region分裂，Leader的信息过旧等都会产生BackOff

二 TSO的分配

概念

需要为大量的事务提供TSO，事务都是并发的

保证TSO单调递增

TSO = physical time logical time ，是一个int64的整型数，时钟精确到毫秒，logical time 1ms分成 262144个TSO ，这个可以满足大多数场景的使用了

分配过程

为我们提供服务的只是PD集群的中的Leader 角色。

谁会请求TSO ，SQL，事务等。

TSO 请求者请求TSO ，并不是直接发送到PD，而是到 PD client 。PD client 可以认为是 TiDB Server 和 PD 集群交互的中间代理模块。

性能问题

如果SQL并发很高，所以有一个优化，PD client 会有一个批处理，会把100个SQL请求TSO的组合整一个请求，去PD中获取TSO。

无论是批处理还是，申请一次都需要进行一次持久化，会产生磁盘IO，并发越高，磁盘IO越大。如何处理了这个问题？

将一段TSO放到缓存中磁盘IO 变为3秒一次

高可用问题

当我的PD leader挂了怎么办？

保证不了连续性但是可以保证增长性

三 PD的调度原理

总流程

1 信息收集

TiKV Server 会周期性的向PD汇报心跳信息，里面包含Store Heartbeat (TiKV 本身的心跳信息，包括容量，剩余空间，读写流量等，通过这些信息大概可以知道TiKV的繁忙程度)和 Region Heartbeat （每个Region都会向PD汇报，比如副本的分布状态，读写流量，这样就可以知道Region的繁忙程度以及 Region在TiKV的分布是否均匀），所以PD是通过心跳的信息收集获取这些信息