TiDB 5.0 跨中心部署能力初探 | 中心化还是去中心化？揭秘 TiDB 5.0 事务分布式授时模块

原创

于 2021-03-02 18:13:41 发布 · 1.5k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#分布式 #大数据 #数据库

TiDB 5.0 发布在即，在这个大版本更新中提升 TiDB 集群的跨中心部署能力是我们重要的一个着力点。其中，新的分布式本地事务能力及其对应的授时服务改造是基础且又重要的一环。本文将会从 TiDB 现有的授时服务出发，一步步阐释新分布式授时服务的改造思路和本地事务的性能表现，最后将会为大家分享一个应用场景与上手步骤，供感兴趣的用户把这个新特性上手试用起来。

单点 TSO 服务

作为一个 NewSQL 分布式数据库，TiDB 自然会从骨子里由内而外地散发着一股分布式系统应该有的气质——高可用且几乎无限的水平扩容能力。事实上，既然决定了走上 Shared-nothing 这条充满未来感的道路，拥有这样的优点自然而然也是无可厚非之事，但如果你仔细打量一番曾经的 TiDB 集群，你会发现在这个无处不分布式的系统里面，有一个东西的存在似乎格外的“独特”——集群的授时服务 TSO。

全局的授时服务器称为 TSO （Timestamp Oracle），名字里虽然有 Oracle，但我相信至少跟 Oracle 数据库没什么关系，仅仅代表其单词本意：“神授的，不可置疑的“。TSO 授时服务可以保证按照递增的方式分配时间戳，任何一次申请得到的时间戳都不会重复，在分布式系统中往往用于给事件定序，最常见和重要的作用即保证事务版本号的单调递增，确保分布式事务的时序。TSO 有实现简单、严格定序、性能好等优点，因此有很多分布式系统采用了 TSO 作为时钟方案，TiDB 也是其中一员，在一个 TiDB 集群中，PD leader 节点会作为全局单点的授时服务进行时间戳分配，为集群的分布式事务，数据隔离级别，版本控制等提供稳固的基石，PD 的 TSO 服务性能也久经考验，可以轻松达到百万级别的 QPS。但你可以注意到一点——TSO 服务是整个集群中的一个单点。一个庞大的分布式系统依赖于一个单点，自然存在着一些问题。

首先是单点故障。整个系统依赖 TSO 的高可用，这个问题我们通过 PD 本身的高可用进行了一定程度上的解决，同时结合 etcd 强一致性的持久化存储也保证了 TSO 在发生服务切换后的不回退。但尽管如此，由于 PD leader 的选举基于 etcd 本身的 Raft 构建，一旦发生网络分区或其他原因触发重新选主，在选举过程造成的不可用问题依然无法避免。

其次是延迟问题。获取时间戳需要 PD client 与 PD leader 进行通信。如下图所示，如果 TiDB 实例和 PD leader 并不在一个机房，延迟就会比较高，更甚者若是全球化跨数据中心部署，这个延迟是跨中心级别的，可能会变得非常大，这样一来势必会对集群的性能产生很大的影响。

上述两个问题，尤其是后者，大大制约了 TiDB 在跨数据中心场景下的部署应用，而单点的 TSO 授时服务便是其中关键的影响因素，试想，如果每个事务的执行都需要容忍跨中心请求时间戳带来的延迟，加之 TiDB 使用了 Percolator 作为事务模型，在写场景下一次事务至少需要 Prewrite 和 Commit 的两次时间戳获取，遇上高强度 OLTP 负载，远在另一个数据中心的 PD leader 显然因为网络延迟成为了整个集群性能的瓶颈。TiDB 其实在 5.0 版本中对写场景做了诸多优化，上述每次事务写都需要的两次 TSO 获取，可以通过开启 1PC 一阶段和异步提交 Async Commit 这两个特性来省去其中一次网络开销，从而提升性能，但其实这两个特性并没有本质上消除跨中心带来的网络延迟问题本身，如何从根源上下手去优化，甚至说彻底抹除这部分延迟带来的影响呢？