tikv/pd：TiKV 集群的调度中枢，单节点起步的 Placement Driver

PD 在 TiKV 体系中的位置

PD 全称 Placement Driver，是 TiKV 集群的调度与元数据管理组件。TiKV 本身是分布式键值存储，但多个 TiKV 节点如何协同、数据分片放在哪里、故障节点如何处理，这些决策由 PD 完成。README 明确指出，PD 通过嵌入 etcd 实现容错。这意味着 PD 的元数据存储依赖 Raft 协议，多个 PD 节点可以组成高可用组。PD 不是独立产品，它必须与 TiKV 一起运行才有意义。如果你只用单机键值存储，PD 是多余的。它的目标用户是部署了 TiKV 集群，需要自动分片、负载均衡和故障转移的团队。

单节点启动：从源码到运行

构建 PD 需要 Go 1.25 或更高版本。在项目根目录执行 make，会生成三个二进制：pd-server、pd-ctl 和 pd-recover。pd-server 是主服务，pd-ctl 是命令行控制工具，pd-recover 用于紧急恢复。单节点运行方式很直接，设置 HOST_IP 环境变量后，用 --name、--data-dir、--client-urls、--peer-urls 和 --log-file 参数启动。默认端口是 2379 用于客户端 API，2380 用于节点间通信。README 给出的示例中，client-urls 使用 http://${HOST_IP}:2379，peer-urls 使用 http://${HOST_IP}:2380。注意这里没有启用 TLS，生产环境需要额外配置加密。启动后可以用 curl 访问 /pd/api/v1/members 查看成员信息，响应包含 cluster_id、成员列表和当前 leader。

Docker 部署：端口映射与地址通告

Docker 方式提供了另一种快速启动路径。你可以从 Docker Hub 拉取 pingcap/pd 镜像，或本地构建。运行命令与直接执行二进制类似，但多了端口映射和 advertise 地址。容器内监听 0.0.0.0:2379 和 0.0.0.0:2380，通过 -p 映射到宿主机。关键区别在于 --advertise-client-urls 和 --advertise-peer-urls，这两个参数告诉其他节点如何访问当前 PD。容器内使用 0.0.0.0 监听，但对外通告必须使用宿主机可达的 IP 地址，即 HOST_IP。如果忽略 advertise 参数，其他 TiKV 节点可能无法正确连接。这个细节在 README 示例中明确展示，是容器部署最常见的配置错误来源。

集群模式：PD 只是起点

README 强调，PD 需要与 TiKV 一起运行才能工作。单节点 PD 只适合本地测试，真实部署需要至少三个 PD 节点构成 etcd 集群，同时搭配多个 TiKV 存储节点。部署方式有两种：使用 TiUP 部署 TiDB 集群，或使用 Kubernetes 上的 TiDB Operator。TiUP 是命令行工具，适合传统服务器环境；Kubernetes 方案适合容器化运维。PD 在其中扮演的角色是调度器，它维护整个集群的 region 分布信息，并根据负载情况做出迁移决策。单个 PD 节点没有容错能力，一旦宕机，TiKV 集群虽然能继续服务，但无法进行新的调度操作。生产环境必须部署奇数个 PD 节点，通常三个或五个。

API 与可观测性

PD 暴露 HTTP API，README 给出了 /pd/api/v1/members 的示例响应。这个接口返回集群 ID、成员列表、leader 信息等基础状态。你可以在浏览器中直接访问，也可以用 curl 或 httpie。API 支持 CORS，响应头包含 Access-Control-Allow-Origin: *，意味着前端应用可以直接调用。这为构建自定义监控面板提供了便利。但 README 没有列出更多 API 端点，实际 PD 还提供 region 信息、调度策略配置等接口，需要查阅官方文档。对于运维人员，pd-ctl 是更常用的交互工具，它可以执行更复杂的操作，比如查看 region 分布、手动触发调度。不过 README 未提供 pd-ctl 的具体用法，这部分信息需要从 TiDB 文档获取。

局限性与误用场景

PD 的设计目标明确，它只服务于 TiKV 生态。如果你需要通用的分布式协调服务，etcd 本身是更直接的选择，PD 只是在其上叠加了调度逻辑。另一个限制是单节点模式没有容错能力，README 虽然支持本地运行，但没有说明这会带来什么风险。在单节点模式下，PD 的 etcd 嵌入层只有一份数据，进程崩溃后数据目录可能损坏。此外，PD 的调度行为默认是自动的，但某些场景下自动调度可能引发问题，比如跨机房部署时延迟敏感的业务可能不希望 region 频繁迁移。README 没有提及如何调整调度策略，这需要深入配置文档。对于纯键值存储且不需要跨节点冗余的应用，直接使用 etcd 或 Badger 这类嵌入式数据库更合适，PD 的复杂度不值得。

维护与升级成本

PD 仓库最近发布了 v8.5.8，版本号与 TiKV 系列保持一致。升级 PD 通常需要同步升级 TiKV 和 TiDB，因为组件间存在 API 兼容性约束。README 没有提供升级指南，但 TiDB 官方文档通常会有版本对应表。维护成本主要来自三个方面：监控 PD 的 leader 选举状态、定期检查 etcd 存储空间、处理调度异常。PD 使用 Apache-2.0 许可证，允许商用和修改，但如果你修改了 PD 代码并分发，需要保留版权声明。对于大多数用户，直接使用官方镜像和二进制是最省事的路径，自行编译需要维护 Go 工具链和依赖版本。pd-recover 工具的存在暗示了故障恢复的复杂性，它用于在 etcd 数据损坏时重建元数据，但这个操作需要谨慎，可能影响整个集群的数据一致性。

编辑结论

PD 适合已经在使用或计划部署 TiKV 的团队，它是集群调度的必要组件，单节点模式可用于本地开发与功能验证。不适合单独使用，因为它本身不存储业务数据，脱离 TiKV 没有意义。若你的场景只需要键值存储而不需要跨节点调度，直接使用 etcd 或其它分布式数据库更轻量。采用前需要验证三件事：Go 版本是否满足 1.25 或更高，确保 2379 与 2380 端口未被占用，以及确认你的 TiKV 版本与 PD 版本兼容，因为 PD 的 API 和调度策略会随版本演进。

官方来源

1. Official README
2. Project repository
3. Release notes