TSO用时间窗口分配，怎么保证不同TIDB server之间的时序？

🪐 TiDB 技术问题
21

这样吧，你这2个事务也不要放在10分钟这个尺度看了。

serverA和serverB都在1ms完成一个事务，2个有先后。

serverA拿到逻辑位1-1000的，开始事务，serverB拿到逻辑位1001-2000的，做serverB的事务，这个时候serverA提交的时候，发现tso用完了，再去pd拿的是逻辑位2001-3000的。

这部分你能理解吧？

假设serverA把这1ms的26w个tso全拿走了，serverB这个时候想要tso，不好意思没有，你下1ms再来拿吧，这就是tso wait。
https://docs.pingcap.com/zh/tidb/stable/dashboard-monitoring#pd-tso-waitrpc-duration

简单来说，pd保证生成一个线性增长的序列，如果生成的慢了，其他tidb server就要等。而pd发出去的tso是绝对不会重复的。

22

其他我都理解了，就这里
有没有可能，1ms内，A -900 提交在后，B-1900提交在前？ 这样事务序列不就反了吗？ 因为TSO是提前分配了给 A，B的。 A-900提交的时候，会不会去判断 B已经用到1900了，就再去重新申请了？

23

commit时候会再次请求获取最新的吧

24

是的，我们就只说提交的时候 commit_ts

25
  1. 需要先明白乐观和悲观的区别，理解 TiDB 两阶段提交，题主的问题我理解只可能发生在乐观事务情况，对于悲观事务在 prewrite 阶段就会检查 ts 进入悲观锁等待
  2. 上面很多人提到了，commit 时会需要向 PD 获取一次 tso，此时 prewrite 已经过了，其他事务不应该能抢先 prewrite 而会进入 backoff retry。 反之如果其他事务先于当前事务 prewrite 成功，则当前事务 prewrite 应该 backoff retry

具体可以看一些官网介绍比如 TiDB 最佳实践系列（三）乐观锁事务 | PingCAP

image
image1834×1038 114 KB

另外 5.0 针对一些特殊 case 做了 1PC 优化 Async Commit 原理介绍丨 TiDB 5.0 新特性 | PingCAP

官网文档对乐观写写冲突的说明： https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts#keyislocked-错误

1 个赞
26

我问的不是事务的问题，是 关于TSO的时间窗口分配模式，怎么保证TSO的全局唯一递增，多个TiDB Server之间不会出现逆序的情况

27

TSO的时间窗口分配模式

这个没问题

  • PD 只管分配 tso
  • TiDB 负责写入 tso

怎么保证TSO的全局唯一递增，多个TiDB Server之间不会出现逆序的情况

上面关于事务的说明已经解答了

28

@yiduoyunQ 说的没问题，这确实是个事务问题。

简单理一下：

A-800 prewrite-》B-1800 prewrite发现有锁，没法prewrite也就没有办法提交-》A-900能提交成功
B-1800 prewrite-》A-800去prewrite就会发现自己的tso比B-1800小，已经过期了，需要重新取tso。-》B-1900 能提交成功

29

基本上明白了，非常感谢不厌其烦回答。跟事务相关，但其实我问的不是一个事务问题。 就是一个TSO在不同TiDB Server之前步调一致，线性一致的问题，。 虽然预先分配了一段，但事务使用TSO的时候，还是会去判断现在所有TIdb server使用了的最大的TSO是多少（在PD里还是TIKV里？），过期了就再去重新申请一段，如果是这个逻辑，就没什么疑问了。

30

您这个标注的过期，指的是 TSO过期吗？

31

https://docs.pingcap.com/zh/tidb/stable/tikv-control#查看给定-key-的-mvcc

你可以看一下这个mvcc key编码的信息。里面会有startts和committs。
如果有其他可以用来判断过期的东西，必然在编码中。如果没有，那这就是唯一的选择。

33

Tidb 使用了混合时钟，与MVCC结合，解决读操作的全局一致性

34

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。