共计 8405 个字符，预计需要花费 22 分钟才能阅读完成。
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 这两个个性来省去其中一次网络开销，从而晋升性能，但其实这两个个性并没有实质上打消跨核心带来的网络提早问题自身，如何从本源上下手去优化，甚至说彻底抹除这部分提早带来的影响呢？
跨核心部署的问题
在跨数据中心部署的场景下，影响 TiDB 性能的关键性因素就是不同数据中心间的高网络提早，具体联合到 TiDB 的运行机制中去，会蕴含以下几个方面：
- TiDB 与 Region（注：TiDB 的数据分片单位）的 leader 不在同一数据中心
- Region 的 leader 和 follower 不在同一数据中心
- TiDB 与 PD leader 不在同一数据中心
因为这些起因，实际中用户往往会设置调度策略把业务申请、Region Leader 以及 PD leader 集中在同一个数据中心。这样做的害处是只有一个数据中心对外提供服务，硬件资源利用率太低，显然是一个“折衷和谐”的非最优解。
继而，为了能多个数据中心提供服务，一些用户会抉择把数据库拆解成多条业务线，每条业务线部署一套跨数据中心的集群，不同业务线在不同的数据中心提供服务。这样做的毛病次要有两个，一是多套集群的运维会更麻烦，二是不反对逾越多个集群的事务。
基于此，咱们冀望有一套这样的计划：能实现多套业务线运行在一套集群内，不同的业务线在不同的数据中心提供服务，当事务只波及到本地数据时，不必累赘跨数据中心的提早开销，而当事务波及到多个数据中心的读写时，又能不毁坏事务一致性。也就是说，为了实现兼顾性能，又反对同一集群跨数据中心部署的重要历史使命，咱们须要对 TiDB 的事务的一致性模型进行革新。
分布式的一致性
作为一个强一致性 HTAP 数据库，TiDB 基于 Raft 共识算法提供了满足强一致性（线性一致性）且高可用的数据库服务，同时在隔离级别上做到了快照隔离 (Snapshot Isolation) 级别（为与 MySQL 保持一致，又称其为“可反复读”）。只管可序列化（Serializability）是最现实且严格并发管制计划，但其实现后所带来的性能却难称高效，TiDB 天然也和诸多老牌数据库系统（PostgreSQL，Oracle 以及 Microsoft SQL Server）一样抉择了多版本并发管制 MVCC（Multi-Version Concurrency Control）来解决并发读写问题。MVCC 中用来代表版本标示的，便是由 TSO 授时服务提供的全局惟一，且严格递增的工夫戳。在 TiDB 集群中，一个 TSO 工夫戳是一个 int64 的整型，它由物理工夫 Physical time 和逻辑事件 Logical time 两个局部组成。
- 物理工夫 Physical time 是以后的 Unix 零碎工夫戳（毫秒）
- 逻辑工夫 Logical time 则是一个范畴在 [0, 1 << 18] 的计数器。这样一来便做到了在每毫秒的物理工夫粒度上又能够持续细化成最多 262144 个 TSO
TSO 作为一个单点，可能轻松地确保工夫戳的全序关系，物理工夫随着天然工夫流逝，更细粒度的定序则由逻辑工夫来保障。同时再引入额定的机制保障高可用与工夫戳不会受零碎工夫错乱的影响而回退，具体能够参考咱们之前写过的对于 TSO 设计的博客。
单点虽好，但如前文所述的跨核心部署场景下，TSO 服务与其余节点间的高网络提早让咱们无奈美妙地享受跨数据中心部署。思考到在具体实际场景中，往往用户的业务是有数据中心关联个性的，即除了少部分事务会进行跨数据中心的数据读写，来自一个数据中心的事务所波及的数据读写往往只会产生在以后数据中心之内，那么对于这部分事务，作为 TSO 授时服务其实只须要保障以后数据中心内的线性一致性即可，如下图所示。
如此一来，数据中心之间的提早不再是大部分事物所要累赘的一部分，即使呈现了须要进行全局事务的场景，咱们也能够通过某种机制来对所有数据中心的 TSO 进行同步，保障全局和本地的线性一致性不被毁坏。总而言之就是要将已经的单点 TSO 服务分布式化，同时兼顾肯定范畴内和全局的一致性保障。于是乎，天然便引出了 TiDB 5.0 中 PD 的一个新 feature——Local TSO。具体到用户层面，即 TiDB 的新性能 Local Transaction 本地事务。
如上图所示，TiDB 会在事务执行过程中通过 TiKV 的 Location Label 和 Placement Policy 性能对数据地位属性就行查看，确保本地事务只被容许读写访问本数据中心的数据。而全局事务则无此限度，能够任意的读写所有核心的数据。本地事务由本地的 TSO 提供授时服务，和执行本地事务的 TiDB 实例同处一个数据中心，无跨核心提早。全局事务由全局的 TSO 提供授时服务，应用须要进行同步计算。
分布式化 TSO
前文说到，很久以来 PD leader 都是作为一个单点提供 TSO 服务的，但既然有了 Local TSO 这个概念，每一个 DC 都要有一个 Local TSO 的调配者，那咱们天然要把 TSO 服务与 PD leader 解藕，作为一个独自的服务在跨核心 PD 集群中进行运作，而这个角色咱们称之为 TSO Allocator。从上述的场景中，咱们能够形象出以下两种 TSO。
- Local TSO，只可服务于拜访单个数据中心数据的本地事务，保障在单个数据中心内的线性增长即可，由 Local TSO Allocator 来进行调配。
- Global TSO，可服务于拜访任意数据中心的全局事务，保障在整个集群范畴内的线性增长，由 Global TSO Allocator 来进行调配。
线性一致性
单点 TSO 的大小是全序的，即任意两个 TSO 均能够确定的比拟出大小，而任意两个 Local TSO 的大小则不再是全序关系，起因也很简略，这两个 TSO 可能别离来自不同的数据中心，因为只需维持在各自数据中心的一致性，节点间不同的零碎工夫，不同的逻辑工夫都会导致它们的 Local TSO 进度不同，从而无奈比拟。本地事务存在的初衷即限定了其只能拜访对立数据中心内的数据，所以咱们能够沿用之前的 TSO 功能设计，惟一的区别是须要为每个数据中心在 PD 节点中选举进去对应的 Local TSO Allocator 提供 Local TSO 服务（能够了解成为每个数据中心提供一个单点的 TSO 服务）并限度其服务的范畴即可（只容许该核心发动的事务申请该核心的 Local TSO 服务），这一点会在之后的可用性局部阐明。
而对于 Global TSO，因为其对应服务的是全局事务，全局事务没有数据拜访的束缚，也就意味着持有一个 Global TSO，咱们须要和之前调配过的所有 Global TSO 以及 Local TSO 建设起全序的比拟关系，即对于任意一个全局事务持有的 Global TSO 工夫戳 t，咱们有：
- 在天然工夫意义上，对于任意产生在 t 之前的事务所持有的工夫戳 t1，要有 t1 < t
- 在天然工夫意义上，对于任意产生在 t 之后的事务所持有的工夫戳 t2，要有 t < t2
满足上述束缚，Global TSO 才能够平安地，保障在存在多个 Local TSO 的前提下，全局范畴内满足线性一致性。而要实现这一点，咱们将 Global TSO 做成了一个算法计算的产物，不再如已经的单点 TSO 一样有存储和推动的逻辑，具体的算法过程如下：
- Global TSO Allocator 与以后集群内的所有 Local TSO Allocator 通信，收集已调配过的最大 Local TSO。
- Global TSO Allocator 将收集到最大的 Local TSO 进行解决后（减少逻辑计数等）作为 MaxTSO 向所有 Local TSO Allocator 发送进行同步。
- Local TSO Allocator 收到 MaxTSO 后判断其是否大于本人的以后 Local TSO 进度，若是，则间接更新内存中的以后 Local TSO 为 MaxTSO，并返回胜利；若否，则不进行更新，间接返回胜利。
- Global TSO Allocator 收集到所有胜利回复，把 MaxTSO 作为 Global TSO 后果返回。
Global TSO Allocator 是通过收集 + 写入这一两阶段的同步过程来满足一个 Global TSO 作为集群内此时此刻最大，且之后也不会呈现比它小 TSO 的束缚。出于兼容性和设计直觉上的思考，Global TSO Allocator 不像 Local TSO Allocator 一样须要独自选举，仍然是由 PD leader 作为 Global TSO Allocator 来对外提供服务。
以一言蔽之，对于 Local TSO 的革新，PD 把原有的「TSO 由 PD leader 单点调配」这个设计剥离，将 TSO Allocator 的选举以及 Local TSO 调配均变成以数据中心为单位的分布式存在。而将 Global TSO 作为和所有 Local TSO Allocator 同步校对后产生的算法后果，即 PD Leader 节点和所有的 Local TSO Allocator 授时服务节点达成一个共识作为 Global TSO 调配的后果。
全局唯一性
因为 TiDB 实例在整个运行过程中，会应用事务开始时获取的 StartTS 作为事务 ID 进行相干状态信息的存储，在一些 Corner Case 下，例如同时执行本地事务和全局事务，亦或甚者在同一个 TiDB 上同时执行两个不同数据中心的本地事务，很可能会因为各自独立的 TSO 进度导致反复 TSO 呈现，这不仅会因为事务 ID 雷同而导致 TiDB 产生未定义的行为，也存在毁坏一致性的潜在危险。
咱们的解决办法也比拟“粗犷”，TSO 的逻辑工夫有 18 位，假如咱们存在一个 3 核心的集群，那么只须要从这逻辑位中拿出低位 2 位，即可用后缀标示的形式举世无双地区分来自 2 个核心的 Local TSO 和 Global TSO 这三种 TSO，保障每一个 TSO 的全局唯一性。
诚然，这不是一个完满的解决方案，思考到作为 TiDB 爸爸的 Google Spanner 那寰球级别部署的数以千计数据中心，一味地让渡逻辑位并不是长久之计，如果开拓太多逻辑位用于后缀，可能会导致 TSO 在高强度的申请中过快的耗尽逻辑位而放慢物理工夫的推动，与实在工夫产生偏差。但在目前，对于实现的复杂度以及必要性上来看，这依然是一个不错的“技术债”解决方案。
可用性
既然作为分布式集群中的服务，天然要保障可用性，Local TSO Allocator 通过选举产生，具体机制借由 etcd 的事务性能实现，所有参选的 PD 通过一次 etcd 事务写入非凡键值，胜利写入者即可入选该数据中心下的 Local TSO Allocator，这一点其实和 PD leader 的选举相似，在此不表，感兴趣的同学能够浏览这篇对于 PD 的性能介绍。只管默认所有 PD 都能够参选某个数据中心的 Local TSO Allocator 竞选，然而咱们也要保障这样的选举优先级：大多数状况下限度某个数据中心的 Local TSO Allocator 只能在该数据中心的 PD 节点中选出，仅在一些极其状况（例如整个 DC 的 PD 节点全副挂掉）容许其余数据中心的 PD 节点为本人服务。
而 Global TSO Allocator 在前文曾经提过了，仍然由 PD Leader 提供，天然也随 PD Leader 的高可用一起保障了。
性能取舍
在实现了性能实现后，咱们联合 Chaos Mesh 在 K8s 环境上对一般事务（旧的单点 TSO），本地事务（Local TSO）和全局事务（Global TSO）的性能体现进行了测试，应用 Chaos Mesh 在不同节点之间注入 50ms 的往返提早来模仿跨核心部署，后果也十分喜人，相比于旧的，受跨核心提早影响的单点 TSO，本地事务应用 Local TSO 让性能失去了成倍的晋升，在 Sysbench 的 oltp_write_only 测试中 QPS 最大体现出了 25～30 倍的差别。下图是在 50ms 跨核心提早下，oltp_write_only 的 TPS 体现
有得必有失，从 Global TSO 的算法自身的机制就可以看进去，要保障全局范畴的线性增长，须要与所有核心的 Local TSO Allocator 节点进行每个至多两次的通信，能够说是把跨核心提早吃到了极致，也就防止不了较大的性能损失，测试后果中相比于旧的单点 TSO 服务，全局事务的 QPS 体现降落了 50% 左右。但数据中心数据本地拜访居多的天然属性也算是均衡了这一点性能短板，在实在应用场景中，大家对全局事务高提早的接受度还是比拟高的。如果业务以本地事务为主，很少进行全局事务或者对全局事务的提早要求不严格，那么这一块的性能取舍还是相当划算的。尽管如此，但咱们还在进一步优化 Global TSO 的获取提早，应用诸如估算一个 MaxTSO 来缩小一次集群内 PD 间通信这类形式来尽可能减少提早代价，使其尽量靠近于旧单点 TSO 授时服务的提早体现。
利用场景
作为用户，什么状况下能够用上 Local Transaction 性能呢？综合上述来看，如果有以下需要和业务特色，那么即为 Local Transaction 的实用场景：
- 心愿部署单集群跨数据中心，且不同数据中心间提早较高
- 数据的拜访呈数据中心相干，即大多数事务局限于数据中心内读写，大量事务有跨数据中心读写需要。
- 对跨数据中心读写的事务提早不敏感，可能承受较高的提早。
综合以上几点，比照不开启 Local Transaction 的 PD leader 提供单点 TSO 服务，假若一共有三个数据中心存在，别离为 DC-1，DC-2 和 DC-3，当 PD leader 选举于 DC-1 时，则 DC-2 和 DC-3 的 TiDB 对本数据中心的数据进行读写也要付出去 DC-1 获取 TSO 工夫戳的提早代价，通过开启 Local Transaction 即可防止这种状况产生，使得每个 DC 均有一个 TSO Allocator 服务于本地事务，同时，仅在有跨数据中心事务的需要时才在不同 DC 之间进行同步。如此一来能够将大多数本地事务管制在低提早，高提早代价仅需大量的全局事务承当即可。
Local Transaction 个性将作为试验个性在 5.0 版本中提供，届时如果想体验 TiDB 新的跨数据中心部署能力，须要通过以下几个步骤。
实例拓扑配置
首先，咱们须要对集群中的 TiDB/PD/TiKV 进行数据中心级别的拓扑划分，假如咱们当初有 3 个数据中心别离为 DC-1，DC-2 和 DC-3。预期布局是每个 DC 内有 1 台 TiDB，3 台 PD 和 3 台 TiKV。咱们须要对这三个组件的 Labels 标签配置进行区域划分，指明不同实例所在的具体数据中心拓扑，以 DC-1 为例：
对于 TiKV 来说，首先须要进行拓扑 label 的配置，咱们目前要求须要应用 zone 这个 label 来作为 DC 级别的配置形容，这一块具体的步骤请参考文档通过拓扑 label 进行正本调度。在实现了对 DC-1 的三台 TiKV 打上 zone=dc-1 的标签并在 PD 的 location-labels 设定好对应键当前，对 TiKV 的配置就实现了。
对于 PD 来说，咱们只须要对这 3 台 PD 的配置里对 labels 配置打上同样的 zone=”dc-1”并关上 enable-local-tso 开关即可。
对于 TiDB 来说，同 PD 一样，只须要在 TiDB 的 labels 配置里打上 zone=”dc-1”即可。不设置 zone 标签的 TiDB 会默认在新建 Session 中进行全局事务；在设置了 zone 标签的 TiDB 实例上，TiDB 会默认进行本地事务，此时你也能够通过手动批改 Session Variable @@txn_scope 的值来手动管制“local”和“global”两种模式。
数据地位配置
在实现了对实例的划分后，咱们还须要对数据进行地位划分，好让 TiDB 正确地检查数据束缚，从正确的 PD 获取 Local TSO，保障本地事务在核心内的一致性。这一块咱们能够通过 Placement Policy 来进行配置，因为目前 Placement Policy 仅反对 Partition 分区级别的管制，所以会须要数据在建表时对应不同数据中心划分好不同分区。举个例子，假如咱们有表 t1 如下：
CREATE TABLE t1 (c int)
PARTITION BY RANGE (c) (PARTITION p1 VALUES LESS THAN (100),
PARTITION p2 VALUES LESS THAN (200),
PARTITION p3 VALUES LESS THAN MAXVALUE
);分区 p1 数据对应 DC-1 内的数据，咱们能够应用以下 SQL 对 t1 表的 p1 分区进行束缚划分：
ALTER TABLE t1 ALTER PARTITION p1 ADD PLACEMENT POLICY CONSTRAINTS='["+zone=dc-1"]' ROLE=leader REPLICAS=1;在设置当前，DC-1 内的 TiDB 仅可通过本地事务拜访 p1 分区的数据，对任何没有设置 zone 束缚的分区或者设置了非 dc-1 的分区数据进行拜访都会被回绝。
实现上述对组件实例和数据的拓扑划分后，对应数据中心的 TiDB 实例即会默认在进行事务时走本地事务，但同时也会自动识别 DDL 等操作，将其转化为全局事务进行，以保障整个集群的 Scheme 信息等元数据统一。
后记
目前，新的 TSO 服务还有许多不那么完满的中央，为了解决跨核心部署场景下的这个最大痛点，咱们对技术计划做了不少衡量，也对既有成绩进行了许多改良。除了这些写进去的变动，咱们还有一众问题须要去思考改良：怎么优化 Global TSO 生成过程进一步缩小耗时？怎么解决网络分区的状况，从而进一步提供 TSO 服务的可用性？怎么让本地事务和全局事务的配置划分更不便优雅？这些都是咱们应该做且正在做的一些持续性工作，各位能够纵情期待每一天都在变得更好的 TiDB。以上便是对 TiDB 5.0 跨核心部署能力中，分布式授时服务和本地事务个性的初探。