# PD 架构
__*PD 架构*__

![left](./student-guide/diagram/PDArchitecture_aa_002_20220509.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 的消息,通常意味着对应节点发生了宕机或者网络隔离。