# PD 架构
__*PD 架构*__

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

`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` 的消息, 通常意味着对应节点发生了宕机或者网络隔离。