分布式数据库-全局时钟

分布式数据库-全局时钟

之前在 ShardingSphere 中基于 TSO 实现了全局逻辑时钟的特性，配合 openGauss 数据库，提供分布式事务实时一致性读能力。下面简单介绍下当时调研的全局时钟方案。

全局时钟作用

为了实现分布式一致性，需要对分布式环境下的操作排序，所以依赖全局时钟。
包括分布式环境下实现分布式数据库全局 MVCC 也要依赖全局时钟。

全局时钟分类

分布式系统获取时间有两种方式：物理时钟 与 混合逻辑时钟。

而由于物理时间全局不统一，分布式系统大部分使用逻辑时间。

常见的全局时钟方案如下：

TSO（Timestamp Oracle）

单点授时（同时只能有一台服务器提供授时服务）。本质是一个单调递增的全局时间戳。

优点：实现简单，不存在不一致问题。

缺点：存在单点问题。

使用：TIDB，polardbx，OceanBase，GoldenDB

HLC（Hybrid Logical Clock）

实现较为复杂。集群内可以有多个服务器同时提供授时服务。

可以保证同一个进程内部事件的时钟顺序，但是解决不了系统外事件发生的逻辑前后顺序与物理时间前后顺序的一致性，会有时间误差。

使用：CockroachDB

TrueTime

逻辑与物理时间的结合，集群内可以有多个服务器同时提供授时服务。需要硬件提供支持。

使用：Spanner

TSO全局时钟服务实现原理

TSO 为64位的整型数值，由物理部分和逻辑部分组成。
高48位为物理部分是 unixtime 的毫秒时间。
低位是内存自增的逻辑时间，是一个 18 位的数值。所以 1 毫秒最多可以产生 262,144 个时间戳（2^18）。

但是TSO存在单点问题，所以一般采用集群部署。

TIDB TSO 实现

单点问题解决：
TiDB 中提供授时服务的节点被称为 Placement Driver，简称 PD。

多个 PD 节点构成一个 Raft 组，这样通过共识算法可以保证在主节点宕机后马上选出新主，在短时间内恢复授时服务。

宕机重启后保证时间戳大于旧主：
PD 向 etcd 申请了一个 “可分配的时间窗口”。

时间窗口的跨度是可以通过参数指定的，系统的默认配置是 3 毫秒。

写入 etcd 成功后，PD 将得到一个“可分配时间窗口”，在这个时间窗口内 PD 可以使用系统的物理时间作为高位，拼接自己在内存中累加的逻辑时间，对外分配时间戳。

由于所有 PD 已分配时间戳的高位，也就是物理时间，永远小于 etcd 存储的最大值。
那么，如果 PD 主节点宕机，新主就可以读取 etcd 中存储的最大值，在此基础上申请新的 “可分配时间窗口”，这样新主分配的时间戳肯定会大于旧主了。

获取时间戳：
对当前逻辑时间戳加1，如果到达最大值，则前面的物理时间增加。

TSO 一般能保证自增值的单调性，但并不能保证其连续性。