过了几个月了，来写一下问题的结论：
1、前期和戚铮老师现场抓iotop确认是jdb2进程占用了大量的io，在受影响时间点TIDB并没有什么大量的读写操作，所以怀疑是磁盘本身存在问题。
2、由于集群是部署在虚拟机的，和dba聊起这个问题，他们反馈mysql集群在凌晨也有磁盘IO满的情况，并且已经确认了是物理机集群所在的其他组件的定时任务影响了mysql的磁盘io，所以我们对于tidb的问题，更坚信是相同的情况
3、配置/bin/dstat -tclmsdrgny 1 58 抓取tidb集群所有主机的磁盘io情况，读写很小，但iowait特别大，并反馈给基础架构同事，让他们确认那个时间点虚拟机所在物理机磁盘情况
4、后续结果和预料的是一致的，在凌晨10分左右，有mysql定时备份任务，该任务跑的时候会吃光交换机到盘阵之间的网络带宽，导致tidb服务不可用。后续把定时任务迁移走并进行限速解决。
结论:虚拟机部署的集群，tidb没有读写的情况下，磁盘io过大（jdb2占了大部分）的情况下，可以考虑在同一个物理机的集群中，是否有其他应用影响了tidb性能