目录
一 PD的架构与功能
PD架构
PD作用
名词解释
路由功能
二 TSO的分配
概念
分配过程
性能问题
高可用问题
三 PD的调度原理
总流程
1 信息收集
2 生成调度
3 执行调度
四 Label的作用
Label的配置
给TiKV打标签
PD配置
0 PD的架构与功能
PD架构
PD集群至少由三个节点构成，PD通过集成了etcd支持自动故障转移，PD 通过etcd的raft保障数据的强一致性，所以在生产中建议奇数个。PD中会有leader角色，其实是个单点，只有在发生故障的时候才会发生选举。PD是TiDB数据库的总控，是整个集群的大脑
PD作用
1 整个集群TiKV的元数据存储，TiDB的执行计划或者SQL语句如何知道去哪个Region中找到相应的数据，哪个region存储在哪个TiKV中
2 分配全局ID 和 事务ID 。例如table_id,index_id 事务ID
3 生成全局时间戳TSO 全局时钟 。例如事务开始，查询开始，事务结束的时间都是由PD授时
4 手机集群信息对Region进行调度，例如某些TiKV的Region较多，产生了热点，需要向其他TiKV进行调度
5 提供label，支持高可用
6 提供TIDB Dashboard
名词解释
Store :对应TiKV 实例，同一个服务器上部署多个TiKV，则这个服务器上有多个store。
Region：每个Region负责存储集群一段连续的数据(默认96M）,每份数据会在不同的TIKV存储多个副本，默认是3副本；每个副本叫peer，peer是有角色的，peer也特指raft中的成员
leader :读写都在leader上，follower 也可以读 打开follower-read
follower: leader 通过Raft 协议把日志传输给的Peer
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的信息过旧等都会产生Back Off
二 TSO的分配
概念
需要为大量的事务提供TSO，事务都是并发的
保证TSO单调递增
TSO = physical time logical time ，是一个int64的整型数，时钟精确到毫秒，logical time 1ms分成 262144个TSO ，这个可以满足大多数场景的使用了
分配过程
为我们提供服务的只是PD集群的中的Leader 角色。
谁会请求TSO ，比如 SQL，事务等。我们统称为TSO请求者 。
TSO请求者 向 PD Client 请求TSO。PD client 可以认为是 TiDB Server 和 PD 集群交互的中间代理模块。
TSO请求者请求PD CLient之后，PD CLient 立即返回给请求者一个 tsFuture 对象。标识 何时向PD发送请求。因为TSO在执行SQL的时候才会被用到，执行SQL之前还会经过解析辨析等过程。
PD Client 向 PD请求TSO的并发可能会很高，这个过程可能会有等待或者阻塞，如果一直等待TSO，可能会阻塞后续流程，另外又因为TSO在执行SQL的时候才会被用到，执行SQL之前还会经过解析编译优化等过程。 所以这一步是异步的。
SQL语句经过解析编译之后会调用tsFuture.wait方法，检测是否分配到了 TSO。如果此时PD也分配TSO ，就可以执行SQL了。
如果SQL语句还没完成解析编译，但此时TSO已经分配完成，PD Client就会一直等待看tsFuture.wait被调用，直到解析编译完成了。
性能问题
如果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是通过心跳的信息收集获取这些信息
2 生成调度
根据收集到的信息 生成Operator
- 均衡：读写均衡 ，存储均衡(Balance Leader Region)
- 热点均衡(Hot Region)
- 集群拓扑
- 缩容
- 故障恢复
- Region merge
3 执行调度
将这些调度发送给region，然后执行这些调度
四 Label的作用
DC 数据中心
Rock 机柜
TIKV 服务器
看上面的图 发现不同的region分布对可用性是有影响的，比如上图中的Rock 4机柜损坏后，region1的两个副本不可用。
DC1不可用后 Region2 不可用。
Region3 分布在不同机房的不同机柜上，是合理的分布方式。
region不可用这么可怕吗？是的 比如某个region中存储了集群的元数据信息 information_schema，用户密码等，导致整个数据库不可用。
默认region是随机分布，PD只能保证同一个TiKV节点上不会有同一个Region的两个Peer,但是不能保证Region的分布。那如如何让Region按自己的意愿分配呢？
通过打标签，为每个TiKV 实例设置一个标签 Label,用于表示这个TiKV在哪个机房，哪个机柜，哪个服务器上，这样PD 就会按照标签约定好的方式将Region分布到不同DC、不同机柜、不同的TiKV上。实际上我的标签是为了让PD 去感知集群的拓扑结构的。
Label的配置
Label的配置是要在两个组件上进行配置
给TiKV打标签
server.lables:{zone:"1",rack:"1",host:"1"}
zone代表DC 数据中心； rack 代表机柜 ；host代表服务器
PD配置
location-labels= ["zone","rack","host"]
[replication]
isolation-level=''zone'
隔离级别设置 ：zone,rack,host，代表副本的分布文章来源：https://www.toymoban.com/news/detail-615454.html
TiDB 数据库的计算 | PingCAP 文档中心文章来源地址https://www.toymoban.com/news/detail-615454.html
到了这里，关于【TiDB理论知识06】PD架构与作用的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
![[Lesson 01] TiDB数据库架构概述](https://imgs.yssmx.com/Uploads/2024/02/561863-1.png)
