TIDB PD 在分布式事务顺序性中TSO考虑的问题

TIDB 在分布式事务的顺序性方面采用了TSO的方式来进行授时， TSO 是一种全局单节点的授时方案，优点是算法简单，实现方便，但需要每个节点都与他进行交互，会产生一些网络通信的成本。TSO的授时中就需要考虑低延迟，高性能以及更好的容错性。

首先要确认的一点TSO 的硬性技术标准是分配的时间戳永远是递增的，先分配的时间戳 T1 永远会 比后分配的时间戳  T2  要小  T1 < T2  。怎么保证分配的时间能达到这个标准，与TSO 本身的时间戳的设计有关，这里TSO 是一个64位的整型，基于两个部分来完成 物理时间 与  逻辑时间，物理时间是当前主机系统的时间， 逻辑时间为 2 的18次 ,通过物理时间+ 262144个逻辑时间来代表整体的TSO 。 

PD 本身由三个节点组成，通过RAFT协议，其中的LEADER 来进行TSO 授时的标准，并且在安全方面的考虑相关的TSO 会存储在ETCD中一份，并且为了不与ETCD频繁的交互，所以制定了一个范围，通过定期将一个时间窗口的时间存储在ETCD中，满足在新的PD 产生后，分发的的时间戳TSO的单调递增小。

之前提到过频繁的通过PD 获取TSO 是需要网络消耗的， 所以PD 的TSO 的获取都是批量的，通过批量的获取事务，在批量的获得TSO ，在进行分配，杜绝频繁的获取和分配。

上面提到过时间的分配都是通过物理时间+逻辑时间的方式，1个毫秒可以保证 262144 的事务分配，如果有人提出如果事务量很大，相关的事务TSO 分配光了，则此时会停止进行分配，并直接等待一定的时间后，在进行分配。

同时在PD 的工作期间还不能忘记LEADER的租约，TSO 在分配中还需要时刻的监控分发TSO的PD 的LEADER 租约的问题。

总结以中心化的授时服务 TSO 主要考虑的问题

 1   TSO 本身的单调递增性

 2   PD 在切换过程中的 TSO 单调递增

 3   TSO 分组批量获得和请求的问题

 4   监控PD LEADER 租约的问题 

 5   切换PD 后的时间调整和校对的问题

 6   TSO 的定期的数据存储的位置与窗口期的设置值

 7   在一个阶段分配完TSO 的等待问题

最终的目的就是TSO的单调递增与顺序性。 所以做一个分布式的数据库的难度要远远大于一个单体数据库中考虑的问题的等级。