目录
一、PD 简介
1.1 元数据管理
1.2 调度决策
1.3 全局服务
1.4 集群设置与管理
二、TiKV 管理
2.1 调度需求
2.2 信息网络
三、TiDB server 管理
四、PD 集群主节点选取
一、PD 简介
TiDB PD (Placement Driver) 是 TiDB 分布式数据库系统中的核心组件之一，负责整个集群的元数据管理和调度工作。PD 在 TiDB 架构中饰演着至关紧张的角色，确保了数据的精确分布、高可用性、以及资源的有效利用。
PD 的功能如下：
1.1 元数据管理
存储集群全局元信息：PD 保存了 TiKV 集群的整体拓扑结构、每个 TiKV 节点的状态、以及数据在各个节点上的分布情况（即 Region 分布）等关键元数据。
维护 Region 信息：Region 是 TiKV 中数据的最小分布单位，PD 负责记录每个 Region 的键值范围、副本位置、Leader 信息等，并动态调解 Region 分布以实现数据平衡。
1.2 调度决策
数据平衡：PD 根据预设的战略（如 Region 大小、副本数、地域分布等）定期进行数据平衡操作，通过迁移 Region 的副本来避免数据热点、保证资源利用率，并确保在节点故障时有足够的副本可用。
故障恢复：当 TiKV 节点发生故障或网络隔离时，PD 负责检测并触发故障转移流程，重新推举 Leader，确保数据的高可用性。
Region Split/Merge：根据数据增长和查询需求，PD 自动触发 Region 的分裂（Split）和合并（Merge）操作，以维持合理的 Region 大小，优化查询性能。
1.3 全局服务
全局唯一时间戳（Timestamp Oracle, TSO）：PD 提供全局单调递增的时间戳服务，用于协调分布式事务中的时间顺序，确保事务的 ACID 特性。
全局唯一 ID 分配：PD 分配全局唯一的 Region ID、Table ID、Index ID 等，确保在整个集群内标识符的唯一性。
1.4 集群设置与管理
设置变更：PD 存储并管理 TiKV、TiDB 等组件的设置信息，支持动态调解设置并通过 gRPC 接口推送变更。
监控与告警：PD 网络集群的运行状态和性能指标，支持通过 Prometheus 等工具进行监控，并提供告警功能。
Dashboard & CLI：提供图形化界面（TiDB Dashboard）和命令行工具（pd-ctl）供管理员查看集群状态、执行管理操作。
二、TiKV 管理
TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个副本 (Replica)，这些副本会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 Raft log。
须要思量一了局景：
- 为了提高集群的空间利用率，须要根据 Region 的空间占用对副本进行合理的分布。
- 集群进行跨机房摆设时，要保证一个机房掉线，不对丢失 Raft Group 的多个副本。
- 添加一个新的 TiKV 节点时，须要合理的将集群中其他节点上的数据搬到新节点上。
- 当一个节点掉线时，须要思量快速的容灾。
- 并不是全部的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，须要通过调度进行负载平衡。
以上题目和场景如果多个同时出现，就不太容易办理，因为须要思量全局信息。同时整个系统也是在动态变化的，因此须要一个中心节点，来对系统的整体状态进行把控和调解，所以有了 PD 这个模块。
2.1 调度需求
对以上题目进行分类和整理，可以分为两个题目：
1. 作为一个分布式高可用系统，必须满足以下要求
- 副本数目要合适，不能多也不能少
- 副本要匀称的分布在不同的呆板上
- 节点宕机能够自动合理的进行容灾
2. 作为一个精良的分布式系统，要思量的方面如下
- 维持整个 Leader 分布匀称
- 维持每个节点存储容量匀称
- 维持访问热点数据匀称
- 控制负载平衡
- 管理节点状态，包括手动上线\下线节点
满足第一类需求后，整个系统将具备强大的容灾功能。满足第二类需求后，可以使得系统整体的资源利用率更高且合理，具备精良的扩展性。
为了满足这些需求，起首须要网络足够的信息，比如每个节点的状态、每个 Raft Group 的信息、业务访问操作的统计等；其次须要设置一些战略，PD 根据这些信息以及调度的战略，制定出尽量满足前面所述需求的调度计划；末了须要一些根本的操作，来完成调度计划。
2.2 信息网络
调度依赖于整个集群的信息网络，简朴来说，调度须要知道每个 TiKV 节点的状态以及每个Region 的状态。TiKV 集群会向PD汇报两类信息，TiKV 节点信息和 Region 信息。每个 TiKV 节点会定期向 PD 汇报节点的状态信息。
TiKV节点(Store)与PD之间存在心跳包，一方面PD通过心跳包检测每个Store是否存活，以及是否有新加入的Store；另一方面心跳包也会携带这个Store的状态信息，主要包括：
- 总磁盘容量
- 可用磁盘容量
- 承载的 Region 数目
- 数据写入/读取速率
- 发送/接收的 Snapshot 数目(副本之间可能会通过 Snapshot 同步数据)
- 是否过载
- labels标签信息
TiKV Store 的状态具体分为 Up，Disconnect，Offline，Down，Tombstone。各状态的关系如下：
Up：表示当前的 TiKV Store 处于提供服务的状态。
Disconnect：当 PD 和 TiKV Store 的心跳信息丢失超过 20 秒后，该 Store 的状态会变为 Disconnect 状态，其时间超过 max-store-down-time 指定的时间后，该 Store 会变为 Down 状态。
Down：表示该 TiKV Store 与集群失去毗连的时间已经超过了 max-store-down-time 指定的时间，默认 30 分钟。超过该时间后，对应的 Store 会变为 Down，而且开始在存活的 Store 上补足各个 Region 的副本。
Offline：当对某个 TiKV Store 通过 PD Control 进行手动下线操作，该 Store 会变为 Offline 状态。该状态只是 Store 下线的中心状态，处于该状态的 Store 会将其上的全部 Region 搬离至其它满足搬迁条件的 Up 状态 Store。当该 Store 的 leader_count 和 region_count (在 PD Control 中获取) 均表现为 0 后，该 Store 会由 Offline 状态变为 Tombstone 状态。在 Offline 状态下，克制关闭该 Store 服务以及其所在的物理服务器。下线过程中，如果集群里不存在满足搬迁条件的其它目标 Store（比方没有足够的 Store 能够继续满足集群的副本数目要求），该 Store 将一直处于 Offline 状态。
Tombstone：表示该 TiKV Store 已处于完全下线状态，可以利用 remove-tombstone 接口安全地清算该状态的 TiKV。
每个 Raft Group 的 Leader 会定期向 PD 汇报 Region 状态。每个 Raft Group 的 Leader 和 PD 之间存在心跳包，用户汇报 Region 状态，主要包括以下信息：
- Leader的位置
- Follwers的位置
- 掉线副本个数
- 数据写入读取速率
PD 不停的通过这两类心跳消息网络整个集群的信息，再以这些信息作为决策的依据。
除此之外，PD 还可以通过扩展的接口担当额外的信息，用来做更准确的决策。比如当某个 Store 的心跳包制止的时间，PD 并不能判断这个节点是临时失效照旧永久失效，只能经过一段时间的等候（默认是 30 分钟），如果一直没故意跳包，就以为该 Store 已经下线，再决定须要将这个 Store 上面的 Region 都调度走。
三、TiDB server 管理
PD 怎样管理和监控 TiDB Server，一下是主要内容：
- 元数据管理：PD 维护整个 TiDB 集群的元数据信息，包括 TiDB Server 节点的列表、状态、设置等。这些信息用于确保 PD 能够准确地知道哪些 TiDB Server 正在运行，以及它们的网络地址、角色（如平常 TiDB Server、TiFlash 服务等）等属性。
- 调度决策：PD 根据网络到的集群状态信息进行智能调度，如负载平衡、故障转移等。如果发现某个 TiDB Server 负载过高或出现故障，PD 会触发相应的调度战略，如将部分 SQL 查询重定向到其他负载较低的 TiDB Server，或者在故障恢复后重新分配 Region 到恢复的节点上。
- 设置推送：PD 可以向 TiDB Server 推送全局或局部的设置变更，如系统参数调解、新功能开关等。TiDB Server 会定期从 PD 获取并应用这些设置更新，确保整个集群的设置一致性。
- 心跳检测与康健查抄：TiDB Server 定期向 PD 发送心跳信息，报告自己的存活状态和负载情况。PD 通过接收和剖析这些心跳消息来监控 TiDB Server 的康健状态。如果某个 TiDB Server 在一段时间内未发送心跳，PD 会以为该节点可能存在题目，并采取相应步伐（如标记为下线、重新调度其负责的负载等）。
- 全局事务协调：PD 分配全局唯一且递增的事务ID给 TiDB Server，用于协调分布式事务。TiDB Server 在发起事务时须要从 PD 获取 事务ID，确保事务的全局唯一性和时间顺序。
四、PD 集群主节点选取
PD（Placement Driver）集群本身也是由多个 PD 节点组成，它们通过 Raft 协议形成一个共识组，共同维护集群的元数据和进行决策。在 PD 集群内部，主节点（Leader）的选取同样遵循 Raft 协议的推举机制。
关于 Raft 选主请参考往期文章：Raft共识算法向导者推举流程揭秘-CSDN博客
总结来说，TiDB 中 PD 集群选取主节点是通过 Raft 一致性协议的推举机制实现的。在推举过程中，候选节点争取大多数节点的投票，赢得推举的节点成为主节点，负责处理处罚集群的元数据管理和调度决策。这种机制确保了 PD 集群在面临节点故障时能够快速恢复服务，维持集群的高可用性和数据一致性。
往期经典推荐：
深入浅出 TiDB MVCC：揭秘分布式数据库中的多版本并发控制-CSDN博客
TiDB内核解密：揭秘其底层KV存储引擎怎样玩转键值对_tidb 的key value是怎样做到的-CSDN博客
揭开Spring Bean生命周期的神秘面纱-CSDN博客
探析Drools规则引擎的工作原理_drools引擎执行过程?-CSDN博客
Raft日志复制技能及成员变更原来是这样的-CSDN博客
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
