PD 组件的Follower节点可以提供时间戳嘛

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】
【遇到的问题：问题现象及影响】
想把TiDB在多个中心上部署，在多数据中⼼场景下 PD leader 位于某个数据中⼼内，数据中⼼间的延迟会造成 TSO 请求延迟增加；PD Follower节点能否有提供时间戳的可能，并和PD Leader提供的时间戳有序，然后PD Follower节点就可以直接将时间戳分配给本中心上的TiDB组件,不需要跨中心获取时间戳了

PD时间戳问题
PD时间戳问题1030×487 6.13 KB

为保证性能 PD 并不会每次为⼀个请求⽣成⼀个 TSO，⽽是会预先申请⼀个可分配的时间窗⼝，时间窗
口是当前时间和当前时间+3秒后的 TSO，并保存在 etcd 内，之后便可以从窗⼝中分配 TSO。我们定期把窗口内的时间提前分配给PD Follower节点，这样所有PD Follower的节点上的时间戳是由Leader统一产生并有序，每个数据中心就可以直接从本地的PD Follower节点上获取时间戳信息了，不知道这样做行不行，希望大佬指点一下

2

目前还不行，可以配置follower转发

tidb_enable_tso_follower_proxy 从 v5.3.0 版本开始引入

  • 作用域：GLOBAL
  • 是否持久化到集群：是
  • 类型：布尔型
  • 默认值：OFF
  • 这个变量用来开启 TSO Follower Proxy 特性。当该值为 OFF 时，TiDB 仅会从 PD leader 获取 TSO。开启该特性之后，TiDB 在获取 TSO 时会将请求均匀地发送到所有 PD 节点上，通过 PD follower 转发 TSO 请求，从而降低 PD leader 的 CPU 压力。
  • 适合开启 TSO Follower Proxy 的场景：
    • PD leader 因高压力的 TSO 请求而达到 CPU 瓶颈，导致 TSO RPC 请求的延迟较高。
    • 集群中的 TiDB 实例数量较多，且调高 tidb_tso_client_batch_max_wait_time 并不能缓解 TSO RPC 请求延迟高的问题
1 个赞
3

好的大佬；就是想问一下如果是改代码的话，这种思路有问题嘛 :joy:

4

能改代码，你才是大佬，可以先看看这个

5

tso要求严格按时间递增，这个只能集中处理，理论上上是不可能分开的，就别想太多了

6

我觉得问的是 local tso 吧？ TiDB 6.0：让 TSO 更高效 | TiDB Books

7

突然发现 local tso 官档上没有。。

8

好吧；还想请教一下，这些时间戳由PD Leader节点先产生，首先是有序的了，然后再把这些有序的时间戳分配到不同的Follower上，这些时间戳在分布式场景下也是有序的吧；跟直接从PD Leader有什么区别了，是说我后一次获取的时间戳肯定大于前一次获取的时间戳；而我提的从Follower上拉取时间戳，做不到全局有序是吗，做不到外部一致性

PD时间戳问题 (1)
PD时间戳问题 (1)856×256 3.51 KB

就像这个，左边数据中心先在时间戳1290时设置x 为 100 ，然后在右边数据中心中拿时间戳1280去读x，发现读不到；但是从外部上来说，是应该读的到的，因为左边的操作是先做的，这种方法就是没符合外部一致性对吧

9

yep，之前看了，用LocalTSO，减少全局事务的出现

10

TiDB BOOKS是好东西啊

11

image
image1409×827 143 KB

Follower 功能只是代理tso请求，自己不缓存tso

12

至于localTSO,那只是实验特性，enable-local-tso这个参数在官方pd参数文档里面根本就没有

13

不直接提供时间戳的功能

14

你发的文档最后提到 “local TSO 作为实验功能尚需完善，TPCC 测试中当开启该功能后出现大量报主键重复错误。”

这东西根本没法用

15

嗯呢，我也学习了，以前没有深入了解过。知道这个特性的时候挺亮眼

16

知识点一个