前言
在 TiDB 里面，为了支持分布式事务，我们通过 PD，这个全局的单点服务，为事务分配全局唯一的时间，这个做法就是简单高效，但获取 timestamp 的时候会有网络开销。这点对一些人来说，就认为我们设计很挫，事务延迟会非常高，从而再推断出 TiDB 性能很差的结论。
对于这些声音，我们通常不予置评，不过这里倒是可以聊一聊为什么我们会考虑使用一个全局授时服务，为什么不考虑其它的一些方案。
在分布式系统的时间这篇文章里面，我已经提到了在分布式系统里面通过时间来确定事件先后顺序的重要性，以及常用的几种方案，这里在重新过一遍。
TrueTime 或者 HLC
TrueTime 是 Google Spanner 里面提出来的一种方案，它采用硬件的方式来解决了分布式时间的问题，但硬件毕竟有误差，所以 Spanner 有一个 commit wait time，也就是必须在等待 2 ε 的时间后，才能保证读取数据的正确性。
最开始 Spanner 的误差是 7 ms 左右，但现在随着硬件的提升，误差应该更小了。但无论怎样，还是有误差的，即使 ε 优化到 1 ms，事务因为 commit wait time 也会有 2 ms 的延迟。但 Spanner 最大的问题在于因为是硬件解决方案，不可能在其他地方大规模的推广，通用性不足。
为了解决这个问题，Kudu 和 CockroachDB 使用了 Hybrid Time 的方案，也就是混合了物理时钟和逻辑时钟，具体的算法大家可以去参考实际的 Paper 以及相关的开源实现，这里不做过多解释。
HLC 虽然没有硬件依赖，但HLC 仍然有一个 bound，需要保证 |l.e - pt.e| 在这个 bound 范围内，如果超过了这个 bound，HLC 就不能正常工作了。所以使用 HLC 仍然有一个 wait time 的问题，只是大家可以选择到底是 commit 的时候 wait 还是 read 的时候 wait。另外，因为 HLC 依赖 NTP，但 NTP 有可能出现同步错误等问题，所以通常 HLC 都会使用一个比较大的 bound time 来容忍 NTP 的异常。譬如，一些 HLC 的实现使用了 250 ms 或者 500ms 的 bound，这个已经非常大了，也就是说，如果我们要完全做到线性一致性，延迟会非常的高。不过如果系统对强一致性不 care，那么也完全可以将这个 bound 设置的非常小，或者压根不处理。
但 HLC 毕竟适用于跨多个 IDC 或者全球化部署的场景，因为这个时候，各个节点之前本身的网络延迟已经非常大了，有可能上百 ms 以上，这时候 HLC 的 bound 问题反倒会弱化不少。因为当消息发到其它节点的时候，减去网络延迟的时间，要 wait 的时间其实就没多少了。
Why TSO
TiDB 的事务模型是基于 Google Percolator 的，所以从一开始，我们就考虑使用的是类似 Percolator 的 Timestamp Oracle（TSO）机制，由 PD 统一进行时间的分配，除了这么做简单之外，还有就是性能的考量。
也许有人会质疑，你都多了一次网络开销了，怎么可能性能好？这个有一定的道理，但要看情况。如果我们的集群在同一个 IDC，网络的开销是非常的小的，通常一次网络请求，都是在 0.1 ms 或者 0.2 ms 就返回，这就是意味着，即使有网络开销，使用 TSO 的方式在一些情况下仍然比 Spanner 或者 HLC 的 lantecy 要低。
如果是跨多 IDC 的场景，虽然网络问题避免不了，我们仍然可以有一些方法来缓解。譬如可以将 TiDB 跟 PD Leader 放在一块， 这样获取 timestamp 仍然很快，只是如果 client 跟 TiDB 没在一个 IDC，这个延迟就可能比较高了。但我觉得，一套系统如果跨多 IDC 部署了，用户也应该能理解网络延迟高的情况，毕竟现在我们还不能超光速传输数据。
其实现在对我们来说，使用 TSO 最大的问题并不是在 TSO 本身，而是坑爹的 Go 调度，时不时会抽风抖动一下，导致获取 TSO 变慢，这个现在我们也正在优化。
小结
使用 TSO 也许并不是最优，但对我们来说，现阶段是最合适的一种方式，没准以后我们可能会考虑其他的方式，但至少不是现在。
而对于 HLC 来说，它虽然能解决很多问题，但也并不是解决分布式时间问题的银弹，并不是所有的系统都适用的。
我个人觉得，即使 Google 没把 TrueTime 的实现开源，但未来这个技术其实很容易搞定，现在一些大厂已经在做了，所以没准 TrueTime 在未来会变成一个通用的解决方案了。
当然，更可能我们推翻了现有的物理定律，能超光速传输数据啥的，不过那时候，我觉得我们应该考虑的是跨星球部署 TiDB 的问题了。
