感谢两位的答复，我学习到了很多知识，但是我仍然是有疑问的，我画了一张图。
假设三个节点A、B、C，在T1的时候做了全备份。
然后在T2时刻有三个分布式交易TD1、TD2、TD3，分别的start ts和commit ts图上有表达。
第一个问题是：Tidb在做PiTR的时候，每个节点的binlog恢复是指定commit ts去恢复日志？还是类似mysql的binlog中只能指定position或者local timestamp去恢复？
在第一个问题中，如果是指定commit ts去恢复，那么就要求分布式交易在每个节点上，将binlog中的日志按照TD1、TD2、TD3这样合并成一个完整的交易去进行日志加载，是这样实现的吗？
如果是类似mysql指定local的position/ts去恢复，那么就要保证在pd拿到的ts靠前的先处理，而且要等这个交易提交成功后才能提交其他的，否则就会出现TD1、TD2、TD3不是顺序而是乱序的情况。
在这种情况下，我可以比较轻松的模拟一个交易TD1，在B节点拿到commit ts=ts2之后，很正常的执行完成了，对应的B节点的local ts也是ts2（NTP保障节点间时间一直，但仍然可以有200ms以上的误差）。而在A节点上，因为某些原因，TD1 的local commit ts并不是ts2，而可能是ts8或者更后面的时间。
这时候，我们采用PiTR指定一个时间点ts2去加载日志，此时B节点几乎正常的加载了TD1的交易，而A节点因为TD1的local commit ts时间是ts8，所以势必就会丢失，造成TD1在做PiTR的时候出现B节点有，而A节点没有的情况。
@maxshuang的答复中，我理解是备份时间点的时候会这么处理，而在PiTR的时候也是这样处理的吗？因为PiTR肯定只是加载日志。
@IANTHEREAL的的答复中，我能理解你想得到一个global checkpoint ts，但是如果只是根据每个节点的最小的local commit ts得出，而不考虑当时这个时间全局所有的分布式交易涉及到哪些节点去判断，实际上还是会出现某些分布式交易恢复不一致的问题。