PD集群中各个节点的压力负担问题

[广泽苍山 (广泽)]

【 问题背景】
阅读了一下PD提供grpc服务实现的代码，发现在心跳，Region操作等实现上都回去先判断当前PD是否为leader，如果不为leader就将请求转发到Leader上去执行这样的操作。

【核心问题】
我的问题是，根据上面的判断，如果所有的工作都交给Pd集群中单个的leader节点去负责执行各类操作。
1.那么当Tidb集群非常大情况下，比如有几百个Tikv节点，这么多的Tikv节点同时在进行心跳信息上传等操作时，PD这个Leader单节点岂不是要承担很的大的压力？并且这种压力是不是也无法通过水平扩容PD集群进行解决？
2.集群存储的数量非常巨大的时候，如果每一个Region的leader都要向PD发送心跳信息，这岂不是很大的一个qps。假如集群存储100T的数据，按照每个region上限324MB，那么需要上传心跳的信息的Region数量为：10010241024/324 = 319687 个region。这么多个region同时去心跳信息，PD的压力岂不是非常大？

[Lucien]

1.那么当Tidb集群非常大情况下，比如有几百个Tikv节点，这么多的Tikv节点同时在进行心跳信息上传等操作时，PD这个Leader单节点岂不是要承担很的大的压力？并且这种压力是不是也无法通过水平扩容PD集群进行解决？

是的，目前最大节点应该是达到 100 多个 TiKV 节点，暂时没有出现边界问题。不过 PD leader 的确承担很大的压力，所以建议还是在性能配置上面给到 PD 节点，比如 PD 里面采用的 etcd 集群，会有 WAL 落盘，落盘最好是 NVME SSD ，加快落盘速度，减少写入延迟等待问题。

2.集群存储的数量非常巨大的时候，如果每一个Region的leader都要向PD发送心跳信息，这岂不是很大的一个qps。假如集群存储100T的数据，按照每个region上限324MB，那么需要上传心跳的信息的Region数量为：100 1024 1024/324 = 319687 个region。这么多个region同时去心跳信息，PD的压力岂不是非常大？

目前 TiDB 针对 region 的心跳提供一个 hibernate region 机制，另外就是 grpc companion
，时间少低频 region 的心跳，另外通过 grpc 压缩传输加快传输的时间。