# PD 架构

![center](./student-guide/diagram/04-PD-Architecture-01-01.png)
-------------------------------------------------------------
PD 是 TiDB 数据库的中心总控，被称为是整个集群的“大脑”。在 TiDB 数据库集群中负责元数据的存储（主要为 TiDB Server 等提供路由），分配全局 ID，事务 ID，全局时间戳 TSO 的生成，服务发现，集群整体拓扑结构、数据实时分布情况和热点状况等信息的收集，并且负责进行 TiKV 节点中数据的调度工作。同时，提供 TiDB Dashboard 的服务。

下面，我们看一下 PD 的架构与组成，PD 本身由至少由 3 个节点构成，PD 通过集成 etcd ，支持 auto failover，无需担心单点故障问题。同时，PD 也通过 etcd 的 raft，保证了数据的强一致性，不用担心数据丢失的问题。生产中，建议部署奇数个 PD 节点。

最后，PD 集群中是由一个 leader 角色的节点对外提供无状态的服务，所有的操作都是被动触发，即使 PD 节点宕机，借助 PD 的选举机制，新选出的 PD leader 也能立刻对外服务，无需考虑任何中间状态。

为了后面的介绍，我们需要同步如下名词：
- Store
  PD 中的 Store 指的是集群中的存储节点，也就是 TiKV 实例。注意 Store 与 TiKV 实例是严格一一对应的，即使在同一主机甚至同一块磁盘部署多个 TiKV 实例，这些实例也会对应不同的 Store。

- Region / Peer / Raft Group
  每个 Region 负责维护集群的一段连续数据（默认配置下平均约 96 MB），每份数据会在不同的 Store 存储多个副本（默认配置是 3 副本），每个副本称为 Peer。同一个 Region 的多个 Peer 通过 raft 协议进行数据同步，所以 Peer 也用来指代 raft 实例中的成员。TiKV 使用 multi-raft 模式来管理数据，即每个 Region 都对应一个独立运行的 raft 实例，我们也把这样的一个 raft 实例叫做一个 Raft Group。

- Leader / Follower / Learner
  它们分别对应 Peer 的三种角色。其中 Leader 负责响应客户端的读写请求；Follower 被动地从 Leader 同步数据，当 Leader 失效时会进行选举产生新的 Leader；Learner 是一种特殊的角色，它只参与同步 raft log 而不参与投票，在目前的实现中只短暂存在于添加副本的中间步骤。

- Region Split
  TiKV 集群中的 Region 不是一开始就划分好的，而是随着数据写入逐渐分裂生成的，分裂的过程被称为 Region Split。
其机制是集群初始化时构建一个初始 Region 覆盖整个 key space，随后在运行过程中每当 Region 数据达到一定量之后就通过 Split 产生新的 Region。

- Pending / Down
  Pending 和 Down 是 Peer 可能出现的两种特殊状态。其中 Pending 表示 Follower 或 Learner 的 raft log 与 Leader 有较大差距，Pending 状态的 Follower 无法被选举成 Leader。Down 是指 Leader 长时间没有收到对应 Peer 的消息，通常意味着对应节点发生了宕机或者网络隔离