TIDB——PD（placement Driver）

前置知识点：

PD至少由三个node构成；PD集成了etcd，PD 的故障转移是基于 etcd 的 Raft 协议内置能力，无需担心单点故障，raft保证数据一致性（建议奇数个node）
pd内node也会有pd leader与follow的称呼，只有leader出现故障时，才会发生选举，出新的leader
Store为tikv node，1:1关系；region 的副本叫做peer（follower）

一、PD的定义与功能以及具体介绍

定位：TIDB的调控大脑
功能
- 存储整个集群的TIKV的元数据
- 分配全局ID（eg：索引ID）和事务ID
- 生成全局时间戳TSO
- 收集对集群信息（eg：TIKV中的region）进行调度
- 提供label，支持高可用
- 提供TIDB Dashboard------具体表现为：当region数据无或者是非常少的时候进行合并
具体功能介绍：
1. 路由功能：
- 实现流程：
  1. TIDB Server内的执行计划交给Excutor；
  2. 将执行计划关系请求（需要的数据）发送给TIKV Client；
  3. TIKV Client向PD请求数据的位置，PD返回路由给TIKV Client后，TIKV Client向对应TIKV node寻找数据，为了减少网络延迟与交互；
  4. 路由会缓存到TIKV Client的region cache，再次读取时就可以减少延迟。

问题：node改变与region cache内的数据过旧
具体操作： tikv client内region cache会存储使用的数据位置，但是当再次使用时，TIKV集群terms时期（leader）变了，会有back off信号，就是寻找的node改变，数据不在，重新寻找数据所在位置，back off 越多，延迟越高
1. TSO分配（异步请求）：
- 定义：64位int型。物理时间（精确到ms）+逻辑时间（1ms，有262144个tso数）
  - 过程
  - 涉及组件：TIDB SERVER 与PD
    - TIDB Server：
      - 凡是要请求TSO的请求（例：sql语句）将此称为TSO请求者
      1. TSO 请求者向PD Client发送请求TSO
      2. PD client
        
        立即返回ts_Future （标记一下tso请求时间）
        
        向PD集群的leader发送请求TSO信息
      3. TSO请求者在TIDB Server
        
        进行解析编译
        
        ts_Future.wait------表示我的工作到位了，需要一个TSO
      4. PD
        
        PD向PD Client分配TSO，TSO请求者获得
    - 需要注意的是PD Client是批处理TSO的请求,但是还是会一个sql语句去点一下PD
      - 具体处理步骤：
        
        因为一个sql语句都会请求一个TSO，这样非常频繁
        
        所以在PD leader内的话，缓存是时间窗口内生成若干TSO，让PD Client的请求直接批量获取，缓存的TSO会存储进行持久化。要是leader宕机后，原本的处理的事务请求有个开始TSO，集群恢复后，会造成TSO间断，我不记得你的开始TSO了，无法恢复，重新在存储的时间窗口的最后时间接着
  1. PD的调度原理：
    - 总流程：信息收集------>生成调度------>执行调度
    - 具体流程：
      1. 信息收集：
        
        TIKV集群会发心跳信息给PD
        
        PD收集的心跳信息分为Store Heartbeat与Region Heartbeat，Store Heartbeat包含节点的存储容量，读写流量等，当然region heartbeat是收集着region的存储容量，读写流量，副本分布状态，读写流量，剩余空间等
      2. PD生成调度（operateor）：
        
        balance：
        
        leader 平衡读写
        
        region 更偏向平衡存储容量
        
        hot region：热点（访问）区域------分散
        
        集群拓扑
        
        缩容
        
        故障恢复
        
        region merge------数据少，空，进行合并
      3. TIKV执行调度：
        
        将operateor发送给节点，让region根据这个自行调整
  2. label的高作用与配置：
    1. 高可用：
    - 场景：假设我们的数据，数据存储在region内，region在TIKV内，这些TIKV node放置在几个机柜上，然后放置在数据中心
    - 规则：就是相同副本的多个region，多数挂掉了我们就会宕机掉
    - 好，那么让我们控制一下
      - 1、要是某一个数据中心区域挂掉了，里面你会放置相同的region在不同的机柜，是不是不太安全？要是游戏的数据库存放的用户数据是不是亏损特别大
      - 2、要是某一个机柜挂掉了呢？里面放置的TIKV node内，你又放置了相同的region在里面，哇塞你是不是又得亏钱了？
      - 解决办法 ：聪明的你想了想要是我放置开多好，但是我怎么控制这个region的位置，我也不可能手动去移动的吧，我调度了，刚好又给我搞回来了呢？，只有PD能控制 吧~我想让它怎么调度，具体的规则需要设定一下
    1. label的配置
      - TIKV：
        在TIKV node节点给1个 servers.label :{zone:"1",rack:"1",host:"1"}
        表示：region在第1个数据中心，第一个机柜，第1个TIKV node上
      - PD:
        local-labels=["zone","rack","host"] $replication$ isolation-level="zone"
        表示标签有这些喔，region的副本以数据中心作隔离级别，即数据中心只有相同副本的1个region

更新于：2025.12.18_22:55------麻了