PD 组件介绍

图：TiDB 集群架构示意，其中 PD 集群由多个 PD 节点组成，TiDB Server 和 TiKV/TiFlash 存储集群通过 PD 进行协同。PD（Placement Driver）是 TiDB 集群的“大脑”和控制中心，负责整个集群 的元信息管理和调度决策 。它保存集群中各 TiKV 节点的实时数据分布和拓扑结构元数据，并提供 TiDB 客户端查询数据的 Region 定位（路由）服务。同时，PD 还负责生成全局唯一的 ID 以及事务的全局时间戳 （TSO），保障分布式事务的一致性 。一个高可用的 TiDB 集群至少需要 3 个 PD 节点（推荐奇数个），这些 PD 节点通过内置的 etcd 协议形成 Raft 集群，确保元数据和调度状态的一致性以及 Leader 选举 。PD 的设计使其本身除少量元数据持久化外几乎无状态，所有操作均由 TiKV 上报的心跳触发，因此即便 PD Leader 切换，新 Leader 也可立即接管并对外提供服务，无需复杂的状态恢复

元信息管理功能

PD 通过定期接收 TiKV 上报的心跳消息来维护全局元信息 。TiKV 节点周期性地向 PD 发送两类心跳： StoreHeartbeat 包含 TiKV 实例（Store）的基本信息（如节点 ID、网络地址、版本、状态、容量和负载等） ；RegionHeartbeat 包含 Region 的键范围、所在的 Peer 列表（包括 Leader）、版本信息 (Epoch)、 以及本周期内的读写流量和数据大小等 。PD 将这些心跳信息整理并存储：在内存中的 BasicCluster 结构里维护各 Store 与 Region 的最新状态，同时在本地 LevelDB（Region 级数据）和内置 etcd（核心配置、 Store 元信息、调度策略等）中持久化保存这些元数据 。利用这些元数据信息，PD 为 TiDB 客户端提供 Region 路由服务：当 TiDB 需要访问某个 Key 时，会通过 PD 客户端查询该 Key 所属的 Region ID 及其当前 Leader 对应的 TiKV 地址，从而将请求发送给正确的存储节点
• Store 元数据： PD 为每个 TiKV 实例维护节点 ID、网络地址、标签（机架、机房等）、版本号、状态 （Up、Offline 等）以及统计信息（容量、可用空间、Leader 数量、Region 数量等）
• Region 元数据： PD 为每个 Region 维护 Region ID、键范围 (start_key、end_key)、版本信息 (Epoch)、包含的所有 Peer 及其中的 Leader，以及该 Region 的读写流量和大小等动态统计值 。若 Region 的大小发生显著变化，TiKV 会触发 Split 或 Merge 操作，并在后续心跳中更新 PD 的 Region 元数据
• 路由服务： PD 的元数据决策存储在 etcd 中，高可用地对外提供查询接口。TiDB Server 内置 PD 客户端可通过 gRPC 向 PD 查询最新的 Region 信息（例如 GetRegionByKey ），从而获得目标 Key 所在 Region 的 Leader 所在的 TiKV 地址，实现全局路由定位

调度系统的机制与策略

PD 的调度系统包括信息收集、调度决策生成和任务执行三个环节 ：
• 信息收集： TiKV 如上所述通过心跳上报集群状态，PD 维护这些状态供调度决策使用 。PD 的 BasicCluster 持有全局的 Store 与 Region 视图，包括节点负载、Region 分布、热点流量等。
• 调度决策生成： PD 支持多种调度器并行运行，每个调度器基于自身策略计算是否需要调整。常见调度器包 括： balance-leader-scheduler （Leader 均衡）、 balance-region-scheduler （Region 均衡）、 hotregion-scheduler （热点均衡）、以及 replica-checker （副本健康检查）等 。各调度器在考虑了如节点状态异常、空间不足、Label 规则等约束后，会生成对应的Operator（调度任务）。Operator 表示对一个 特定 Region 进行的一系列操作，例如 TransferLeader、AddPeer、RemovePeer、MergeRegion 等 。这 些 Operator 会按照优先级进入调度队列，等待执行。
• Operator 执行： PD 的 OperatorController 异步地从队列取出 Operator，并依次将 Operator 中定义的每 一步（Operator Step）下发给对应 Region 的当前 Leader 。例如，TransferLeader 会将某 Region 的 Leader 转移到新的 Peer，AddPeer 则在指定 Store 增加一个副本。TiKV Leader 在收到这些指令后执行相应的 Raft 操作完成数据迁移。Operator 执行完成后被标记为完成或超时移除。整个过程由 PD 完全被动触发（PD 仅在响应 Region 心跳时下发 Operator），PD 节点之间通过内置 etcd 保证调度信息的一致和可靠 。 具体调度策略包括：Region 均衡（通过 balance-region-scheduler 分散各节点上的 Region 数量或大小 ）、Leader 均衡（通过 balance-leader-scheduler 分散各节点上的 Region Leader 数量 ）、热点均衡（通过 hot-region-scheduler 将高读/写流量的 Region Leader/Peer 分散到负载更低的节点 ）、副本健康与补偿（由 replicaChecker 等检查器负责，如缺少副本或副本数量不符规则时生成增加/删除副本的 Operator ）。此外，PD 还支持拓扑感知调度（根据机房/机架标签防止副本集中）和Region 合并（由 mergeChecker 对满足合并条件的相邻 Region 进行合并调度）

时间戳分配服务（TSO）

PD 集群还承担全局时间戳分配器（TSO）的角色，为事务提供单调递增的时间戳以维护一致性 。PD 使用中心化的混合逻辑时钟（HLC）方案：每个时间戳由 64 位表示，其中高位为物理时间（毫秒），低 18 位为逻辑增量 。PD 集群通常由 3 个节点组成，仅 Leader 提供 TSO 服务，Leader 保证每次分配的时间戳大于之前所有分配值。PD Leader 每次从 etcd 读取上一个 Leader 持久化的最大时间戳（t_last）进行校时 。然后 Leader 会预分配时间窗口（默认 3 秒长度）：将 T_last = T_next + window 写入 etcd，之后在内存中连续分配 [T_next, T_next+window) 之间的所有时间戳 。这样做既减少了频繁写 etcd 的开销，又能保证即便 Leader 宕机，后续 Leader 仍可从 etcd 读回 t_last 继续分配。客户端一次请求可申请多个时间戳，PD 会返回包含物理和逻辑部分的混合时间戳值 。当逻辑位分配耗尽时，PD Leader 会暂停至物理时钟前进（或每 50ms 主动推进物理时钟），并在必要时再次向 etcd 更新新窗口 。PD 通过这种中心化 HLC 方案（结合 etcd 保证单主），确保在分布式环境下为所有事务生成全序的时间戳
PD 的高可用与 etcd 选主机制
PD 自身具有高可用特性： 一般建议部署奇数（≥3）个 PD 节点 。每个 PD 节点都运行一个嵌入式 etcd 实 例，整个 PD 集群在内部形成一个 Raft 共识组 。PD 集群中只有一个 Leader（也是 etcd Leader）承担所有对外服务，包括调度和 TSO 分配。若当前 Leader 宕机，剩余节点会首先在 etcd 层面选举出新的 Leader （最长保持 Lease 的节点胜出），然后通过写入 //leader 键选出 PD Leader 。选举完成 后，新 Leader 会读取 etcd 中持久化的元数据并继续提供服务。由于 PD 的操作主要依赖心跳触发且大部分中间状态无需显式存储，所以新 Leader 可以几乎无缝接管工作，继续下发调度 Operator 和分配时间戳 。整个过程通过 etcd 的 RAFT 保证强一致，PD 因而避免了单点故障，保证了元数据服务和 TSO 服务的持续可用。
PD 使用 etcd 作为仲裁服务： 当 Leader 宕机时，首先选举出新的 etcd Leader，再选出 PD Leader 。新的 PD Leader 继续注册 Lease 并从 etcd 加载先前写入的最新时间戳及调度 状态，接着恢复 gRPC 服务（TSO、调度接口等） 。原 PD Follower 则持续监听 Leader Key（ / /leader ），一旦该键过期或删除便会参与下一轮 Leader 竞选

PD 与 TiDB/TiKV 的通信与交互流程

PD、TiKV 和 TiDB 之间通过 gRPC 接口进行通信 ：
• TiKV → PD： 每个 TiKV Store 进程内的 PD Worker 会定期向 PD Leader 上报 StoreHeartbeat 和 RegionHeartbeat（如前所述），携带当前节点和 Region 的状态 。PD 接收到心跳后更新内部元数据，并在 RegionHeartbeat 的响应中携带调度命令（如果有）下发给该 Region 的 Leader 。PD 不主动发起指令，所有调度都通过心跳回复下发给 TiKV 执行
• TiDB → PD： TiDB Server 进程中的 PD Client 通过 gRPC 与 PD 集群交互 。TiDB 会向 PD 请求获取全局事务 TSO（ GetTimestamp ），以及根据 SQL 查询 Key 向 PD 查询 Region 位置信息（如 GetRegionByKey 请 求）以确定数据所在的 TiKV 节点。PD 返回对应的时间戳或 Region 元数据（包括 Region ID、Leader 所在 Store 地址等），TiDB 再将后续的 KV 操作下发给正确的 TiKV 节点 。新版本还支持 Active Follower： 当客户端（TiDB）请求 Region 信息时，可由 PD Follower 直接提供信息（减轻 Leader 压力）
• 工具与监控： PD 还提供 HTTP/gRPC 管理接口和 Dashboard，可通过 pd-ctl 查看集群状态或修改调度参数。TiDB Dashboard 也通过 PD 暴露的元数据接口展示集群拓扑和热点信息