为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
但是实际跑起来，3个tikv cpu使用率能达到200%~400%， 但是pd的cpu使用率只有1-2%；
而且实际测试的iops也没有很高， 并没有比单tikv跑的更高
请问 是不是我部署的有问题 还是我对pd的理解有问题
不是部署问题，PD 主要负责的工作分发 TS、热点调度、balance 调度、region 元信息管理。如果目前 TiKV 存储的数据量不大，CPU 的消耗不会高，不过可以准备一些预留负载空间。
slack 和 AskTUG 里面的解释的内容点不一样。首先 PD 是单副本提供服务的，其他的 2 副本的 PD 节点是为了提供高可用，PD 的副本节点数据读写算法是遵循 Raft 算法的。 PD 的副本和 TiKV 的副本是两个维度，存储的数据不没有关系的。PD 存储的副本数据是包括 Region 元数据地址信息以及调度、参数相关数据。 TiKV 存储的副本是业务写入的数据信息就是 key-values 数据。
tikv的副本数量如何配置, 就用我们需要的场景: 一个PD, 三个tikv做单副本
不太建议这种使用方法，相当于 TiKV 使用 1 副本，目前生产环境用户场景都是默认 3 副本或者 5 副本。如果需要 1 副本的场景，可以看一下 TiKV 的参数配置。
https://docs.pingcap.com/zh/tidb/stable/pd-configuration-file#max-replicas
我们tikv后端是分布式块, 本身就是高可用的 所以tikv单副本不是问题
如果后端存储是分布式存储，且自带副本高可用，那么理论上，当 tikv server 所在磁盘无法使用，且 tikv server 能够正常运行的情况下分布式存储的副本可作为数据盘继续使用。
但看官方的配置建议不管是非云环境还是云上，都建议使用本地盘。所以，如果计划使用 tikv region 单副本 + 分布式存储这个方案，建议性能和高可用做下充分的測試～
以下仅为个人见解，如果有误，请轻拍：
即使是这个方案，感觉并不能完全覆盖全部的故障风险，比如因非磁盘问题导致的 pd 不可用，此时 tidb 集群基本处于无法使用的状态，因为 pd 需要分配全局 tso。这时，可能还是需要借助官方提供的 pd-recover 来恢复 pd server如果是 tiup 部署，并且是非磁盘访问的问题导致 tikv1 不可用。此时，这部分数据处于不可访问的状态，即使是从新部署一个 tikv4 ，并且仍然挂载 tikv1 的数据目录，在使用 tiup 部署 tikv4 时，会检查 tikv4 的数据目录是否为空，如果不为空，则 tiup 报错退出～
另外，后面如果整套架构以及破坏性测试满足前端业务 RTO，RPO 的需求，方便将整个的测试结果贴出来嘛，也学习一下 
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。