导读git
在分布式数据库系统中，为了解决不一样集群、节点事件发生的前后顺序问题，时钟同步相当重要。本文将为你们介绍业界现有的几种主流的时钟同步解决方案，以及分布式数据库 ZNBase 基于原子钟技术实现的 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)并发
物理时钟即机器本地的时钟，而因为设备硬件不一样，自己存在误差，一天的偏差可能有毫秒甚至秒级，因此须要对不一样的机器时钟进行同步使得机器之间的时间进行相对统一。一般使用中心化的全局时间同步来保证各节点的时间统一。app
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 万年差一秒。
固然，这种方案的缺点也显而易见，由于是结合硬件实现的解决方案，成本高昂，难以在其余地方大规模推广。
ZNBase 的原子钟方案
ZNBase 是由浪潮开源的一款 NewSQL 云原生分布式数据库，与 CockroachDB、TiDB 同样同为参考自谷歌的 Spanner+F1 论文设计，具有强一致、高可用分布式架构、分布式水平扩展、高性能、企业级安全等特性。其时钟同步方案通过优化迭代，目前采用的也是业界领先的 ture-time 方案。
ZNBase 最初采用的时钟同步方案也是 NTP 对时+HLC。因为前文提到的 NTP 协议存在偏差的问题，致使集群内节点存在 500ms 左右的偏差，很大程度上影响了数据库的高并发性能。为解决这一问题，ZNBase 团队决定舍弃 HLC 模块，引入更高精度的原子钟+PTP 协议，实现了本身的 ture-time 方案。
PTP 即精确时间同步协议，是一种在硬件层面实现的时间同步协议，通常采用硬件时间戳，并配合比 NTP 更高精度的延时测量算法。PTP 能够直接在 MAC 层进行 PTP 协议包分析 , 这样能够不通过 UDP 协议栈 , 减小 PTP 在协议栈中驻留时间 , 从而提升时间同步的精确度。
如下是 ZNBase 团队针对 NTP 与 PTP 进行的实验对比数据：
经过在不一样并发场景下的压测 TPMC 结果，原子钟与原有方案的性能数据相比，原子钟方案性能提高 10%-20%。而且，原子钟方案与原有方案相比，更加适合高并发及事务冲突场景。
因为谷歌 Spanner 的 true-time 机制是配合原子钟+GPS 的硬件实现的，相关的软件部分并未开源，没法直接照搬或借鉴。ZNBase 团队在落地自身的 ture-time 机制过程当中遇到了诸多挑战。
针对这种状况，ZNBase 研发团队查阅了大量的论文及技术资料，研究 true-time 的技术理论，经过前期的大量压测及开展校企合做的方式，并与大学科研机构开展相关子课题的研究。最终，经过大量理论与实践研究的工做，ZNBase 实现了现有的原子钟方案。
目前，ZNBase 的 true-time 方案基于高精度时间同步主时钟实现。支持 PTP/NTP/GPS/北斗/原子钟五种模式。使用 GPS/北斗做为参考时钟时，跟踪 UTC 的精度优于 100ns，可经过以太网提供百纳秒级的时间信号源，极大地缩小了不一样服务器之间的时钟偏移范围。
高精度时间同步主时钟
经过将 NTP+HLC 方案优化成 PTP+原子钟方案，ZNBase 将集群内的节点偏差控制在了 1ms 之内，解决了异地多中心部署时，分布式节点间时钟偏差较大的问题。
本文介绍了分布式数据库系统经常使用的几种时钟同步解决方案，以及 ZNBase 的时钟同步方案的优化迭代过程。欢迎对相关技术感兴趣的朋友留言讨论，不足之处也欢迎指出。
关于 ZNBase 的更多详情能够查看：
官方代码仓库：https://gitee.com/ZNBase/zn-kvs
ZNBase 官网：http://www.znbase.com/
对相关技术或产品有任何问题欢迎提 issue 或在社区中留言讨论。同时欢迎广大对分布式数据库感兴趣的开发者共同参与 ZNBase 项目的建设。
联系邮箱：haojingyi@inspur.com