共计 3831 个字符，预计需要花费 10 分钟才能阅读完成。
导读
在分布式数据库系统中，为了解决不同集群、节点事件产生的先后顺序问题，时钟同步至关重要。本文将为大家介绍业界现有的几种支流的时钟同步解决方案，以及分布式数据库云溪数据库基于原子钟技术实现的 Ture-time 机制。
业内的时钟计划
目前业内支流的分布式数据库系统中，采纳的时钟同步计划各不相同。
国内比拟热门的 TiDB 和 OceanBase 应用的是 Timestamp Oracle（TSO）计划，即中心化授时计划。TSO 采纳单工夫源、单点授时的形式实现全局时钟，用一个全局惟一的工夫戳作为全局事务 id。其中，TiDB 的事务模型是基于 Google Percolator 的，所以从一开始就应用的是相似 Percolator 的 TSO 机制。TiDB 通过集群治理模块 PD 对立进行工夫的调配，以保障整个零碎工夫的全局同步。这种模式的劣势是实现简略，在同一个数据中心下网络开销十分小，但在跨地区的应用场景中提早较高。并且，中心化授时计划会成为整个零碎的性能 bottleneck，且授时服务的单点故障会间接导致整个分布式集群的不可用。
此外，CockroachDB 采纳的是 HLC 作为时钟同步计划；Google 的 Spanner 应用的是联合原子钟 +GPS 硬件的 ture-time 机制，实现了全球化低提早部署。
理解时钟同步
数据库的外围就是将每一个事务的操作进行排序，在传统的单机架构下，事务的排序能够通过日志序列号或事务 ID 轻松实现。然而在分布式架构下，数据库运行在多台服务器上，每个数据库实例有独立的时钟或日志（LSN），而服务器和服务器之间时钟点有快慢之差，所以分布式数据库下的时钟无奈反映全局的事物程序。作为分布式数据库的关键技术之一，时钟同步技术就是为了解决分布式数据库中事件产生的先后顺序问题而存在。
随着分布式系统规模的不断扩大，不同集群和不同节点的工夫同步问题变得异样简单。目前，分布式数据库业界广泛采纳的时钟同步计划包含物理时钟、逻辑时钟、向量时钟、混合逻辑时钟、True-Time 机制五大类。
1. 物理时钟 (PT)
物理时钟即机器本地的时钟，而因为设施硬件不同，自身存在偏差，一天的误差可能有毫秒甚至秒级，所以须要对不同的机器时钟进行同步使得机器之间的工夫进行绝对对立。通常应用中心化的全局工夫同步来保障各节点的工夫对立。
NTP 是目前比拟罕用的同步工夫的形式。NTP 协定（Network Time Protocol）是用来使计算机工夫同步化的一种网络协议，它能够使计算机对其服务器或时钟源（如石英钟，GPS 等等 ) 做同步化，能够提供较高精准度的工夫校对。其机制为 C/S 架构，即每台机器上存在一个 NTP 的客户端，与 NTP 的服务端进行同步，校准本地的工夫。
然而，在分布式数据库中采纳 NTP 协定进行对时，仍会存在 100-500ms 的误差，这会造成分布式节点间时钟误差较大，从而影响数据库的高并发性能。
2. 逻辑时钟 (LC)
逻辑时钟是由图灵奖得主 Leslie Lamport 于 1978 年提出的概念，是一种在分布式系统中用于辨别事件的产生程序的工夫机制。逻辑时钟没有任何一个核心节点来产生工夫，每一个节点都有本人本地的逻辑工夫，次要通过 happened-before 关系确定事务的逻辑程序，从而确定事务的偏序关系。
比方在两个不同的实例中，A 节点先产生事务 1，事务 1 与其余任何节点没有产生分割，此时 A 节点逻辑时钟 +1，其余节点不变；A 节点再产生事务 2，事务 2 与 B 节点产生分割，此时 A 节点逻辑时钟 +1，B 节点逻辑时钟间接 +2，从而与 A 节点时钟同步。通过在两个时钟之间建立联系，将两个节点之间的逻辑时钟同步，这时候就构建了它们之间的 happened-before 的先后关系，代表 A 节点的事务是在 B 节点的新事务开始之前实现的。
分布式数据库中，如果两个事务没有操作同样的节点，则两个事务是无关的事务。无关的事务能够认为是没有先后顺序的。然而当一个事务横跨多个节点的时候，将多个节点之间的关系建设起来，就变成有关系的事务，构建的是事务间的因果序。
而逻辑时钟的问题次要在于仅能保障同一个过程内的事件有序执行，当波及到不同过程时，无奈确定适合的全序关系，容易造成抵触。
3. 向量时钟 (VC)
向量时钟是在 Lamport 算法根底上演进的另一种逻辑时钟办法，它通过向量构造，不仅记录本节点的 Lamport 工夫戳，同时也记录了其余节点的 Lamport 工夫戳，因而可能很好形容同时产生关系以及事件的因果关系。
向量时钟在每个节点存储一个向量，向量的每个元素就是各个节点的逻辑时钟，实质上是通过存储所有节点的时钟备份来解决逻辑时钟的抵触问题。但因为时钟向量的维度等于节点数量，因而空间复杂度较高，影响了数据库存储和传输的效率。
4. 混合逻辑时钟 (HLC)
混合逻辑时钟是一种将物理时钟和逻辑时钟进行组合的解决方案。
混合逻辑时钟把分布式下的时钟切成两局部，上半局部用物理时钟来填充，下半局部用逻辑时钟来填充。即在物理时钟的根底上，在肯定的偏差范畴内引入逻辑时钟进行校准，尽可能使得两者达成统一。其核心内容包含以下 4 点：
（a）满足 LC 的因果一致性 happened-before。
（b）单个时钟 O(1) 的存储空间（VC 是 O(n)，n 为分布式系统下的节点个数）。
（c）单个时钟的大小有确定的边界（不会无穷大）。
（d）尽可能靠近物理时钟 PT，也就是说，HLC 和 PT 的差值有个确定的边界。
混合逻辑时钟一共 64 位，前 32 位示意物理时钟，后 32 位用于逻辑计数。
前文提到的物理时钟同步精度问题也是 HLC 目前面临的次要问题之一。在云原生的 NewSQL 数据库中，应用 HLC 时钟也须要在物理时钟层面进行高精度对时。然而基于 NTP 的 HLC 协定，在局域网下的提早较小，误差小，但在广域网下时缩短而且不稳固，对于多地区的分布式集群来说误差很大，极大的限度了云原生 NewSQL 数据库的并发量。如何晋升对时精度，从而晋升云原生 NewSQL 数据库的读写并发量，成为一个亟待解决的问题。
5. True-time 机制
True-time 机制是 Google 公司在 Spanner 论文中提出的工夫同步机制，该机制假如零碎中每台机器产生的工夫戳都有误差，整个零碎中达成了对于工夫戳误差范畴的共识，进而提早提交事务，延迟时间和工夫戳误差无关，因而谷歌每个数据中心都部署了基于 GPS 和原子钟的主时钟服务器，保障延持提交的等待时间尽可能短。
True-time 实质上是确保两个服务器之间时钟偏移在很小的范畴之内，因而对机器的物理时钟精度提出了极高的要求。Google 通过在各个数据中心部署低廉的原子钟 +GPS 零碎，来同步数据中心里各个机器的工夫。与传统石英钟一天毫秒甚至秒级的误差相比，原子钟的精度可达到 2000 万年差一秒。
当然，这种计划的毛病也不言而喻，因为是联合硬件实现的解决方案，老本昂扬，难以在其余中央大规模推广。
云溪数据库的原子钟计划
云溪数据库是由浪潮开源的一款 NewSQL 云原生分布式数据库，与 CockroachDB、TiDB 一样同为参考自谷歌的 Spanner+F1 论文设计，具备强统一、高可用分布式架构、分布式程度扩大、高性能、企业级平安等个性。其时钟同步计划通过优化迭代，目前采纳的也是业界当先的 ture-time 计划。
云溪数据库最后采纳的时钟同步计划也是 NTP 对时 +HLC。因为前文提到的 NTP 协定存在误差的问题，导致集群内节点存在 500ms 左右的误差，很大水平上影响了数据库的高并发性能。为解决这一问题，团队决定舍弃 HLC 模块，引入更高精度的原子钟 +PTP 协定，实现了本人的 ture-time 计划。
PTP 即准确工夫同步协定，是一种在硬件层面实现的工夫同步协定，个别采纳硬件工夫戳，并配合比 NTP 更高精度的延时测量算法。PTP 能够间接在 MAC 层进行 PTP 协定包剖析 , 这样能够不通过 UDP 协定栈 , 缩小 PTP 在协定栈中驻留工夫 , 从而进步工夫同步的精确度。
以下是研发团队针对 NTP 与 PTP 进行的试验比照数据：
通过在不同并发场景下的压测 TPMC 后果，原子钟与原有计划的性能数据相比，原子钟计划性能晋升 10%-20%。并且，原子钟计划与原有计划相比，更加适宜高并发及事务抵触场景。
因为谷歌 Spanner 的 true-time 机制是配合原子钟 +GPS 的硬件实现的，相干的软件局部并未开源，无奈间接照搬或借鉴。研发团队在落地本身的 ture-time 机制过程中遇到了诸多挑战。
针对这种状况，研发团队查阅了大量的论文及技术材料，钻研 true-time 的技术实践，通过后期的大量压测及发展校企单干的形式，并与大学科研机构发展相干子课题的钻研。最终，通过大量实践与实际钻研的工作，云溪数据库实现了现有的原子钟计划。
目前，云溪数据库 的 true-time 计划基于高精度工夫同步主时钟实现。反对 PTP/NTP/GPS/ 北斗 / 原子钟五种模式。应用 GPS/ 北斗作为参考时钟时，跟踪 UTC 的精度优于 100ns，可通过以太网提供百纳秒级的工夫信号源，极大地放大了不同服务器之间的时钟偏移范畴。
高精度工夫同步主时钟
通过将 NTP+HLC 计划优化成 PTP+ 原子钟计划，云溪数据库将集群内的节点误差管制在了 1ms 以内，解决了异地多核心部署时，分布式节点间时钟误差较大的问题。
总结
本文介绍了分布式数据库系统罕用的几种时钟同步解决方案，以及云溪数据库的时钟同步计划的优化迭代过程。欢送对相干技术感兴趣的敌人留言探讨，不足之处也欢送指出。
