10点时，提前分配给了 TiDB server A，3秒的TSO，但还没有用到，事务A1到10：10分提交。 10：05的时候分配了3秒的TSO给 server B，事务B1，立马提交用了， 怎么保证A的事务的时间戳在B之后呢？
哪个地方理解错了呢？
我记得tso在执行dml时候还需要再申请一次，不知道是不是这样
10：00：00点到10：00：03的tso给了a，a到10：10：00要提交事务，这个时候分配的tso已经过期了，要重新申请的。
https://docs.pingcap.com/zh/tidb/v8.3/tso-configuration-file#tso-update-physical-interval
实际上，一个物理时钟周期默认设置是50ms。到不了3秒钟。
提交的时候需要再申请时间戳
事务开始之前有开始时间戳，事务提交结束有结束时间戳
3s只是举个例子。 10:00-10.03 事先分配了TOS给server A， 那别的Tidb server B，在这3S内发生的事务，怎么使用TSO呢，就是事先分配的方法和绝对的事务时序怎么保证？难道是 Tidb server以分配窗口为时间单位，通过串行事务来保证吗？
dml是要获取两次tso。提交也会获取一次
这个还要看请求时间和提交时间的吧
pd不会把3s内的所有的tso都分配给一个server，1秒就有2^18，用不完
他肯定不可能 只是一个开始时间的tso，如果你一直不提交，等其他事务提交之后在提交，这种事情在生产中肯定也是频繁发生的，第一个A事务真正提交的时候，他会在获取一个tso值，一个开始tso一个commit tos
tso是物理毫秒时间+18位2进制逻辑位。
同一个物理时间的毫秒时间片上，可以产生26w个逻辑分片。
就算是在一毫秒的时间单位上，也不可能serverA全占了这26w个逻辑分片。所以就算物理时间卡死在1毫秒上，也可以通过逻辑位保证分配的tso不重复。
而且tso不管怎么请求，它必须是线性的。即便server时钟回调，也不能影响这一点。
参考上面这个回复。
理解 TSO可以不重复，可以很小细的粒度，这个是没有问题的。 只是对 分配窗口和线性时序的关系不理解。因为是提前分配给tidb server A的，那这段时间（不管多小粒度）内的事务必须都在都A执行内了？如果这段时间还在tidb server B上执行了事务，怎么保证A内的事务和B内的事务的先后呢？ 也就是说，是不是Tidb server以分配窗口为时间单位，通过在不同Tidb server之间串行事务来保证呢?
begin和commit各有时间戳的。
1 个赞
A 事务提交时需要检查数据库里对应数据 commit ts，如果比它还小说明已经有其他事务提前提交了
能详细解释一下吗？
1毫秒能产生26w个逻辑位（2的18次方），你serverA总不能1毫秒26w个全用了吧。serverA这1ms从26w申请一部分，有的是tso给别的server申请，而且下一毫秒还有新的26w个tso的产生。
你要说担心系统事务太多，1毫秒就能用掉26w个tso我还是可以理解的。你担心这几个server会重，我是真的很难理解。
没有说担心重复，我是问怎么保证先后时序的问题，课程上说提前分配了给tidb server A的一段TSO，这段时间，别的tidb server B在这段时间发生的事务，怎么跟 A保证先后，不是说重复的问题
比如说3S，就是提前给了 A 3S 的TSO，如果B在这3S内发生了事务，怎么申请TSO呢？ 是B在申请了后，A的那个3S的TSO段就作废了吗？还是B从A里面拿呢？ 怎么保证TSO在多个tidb server是绝对串行的？ 我的哪个地方理解错了呢？ 您说的细粒度是没问题。
“有的是tso给别的server申请”， 不是事先都给了 server A吗？ 还是B也能从A里拿？还是说 事先分配的，还在PD里面，没有具体给到tidb server。 还是要用到再想pd申请呢？