关于tidb向pd申请tso和数据写入到region中的相关疑问

请教大家两个问题,在学习302课程中有点不解
1、课程中讲到了为了防止tidb server 申请tso时和Pd频繁的交互,pd会给每个tidb server分配一个3秒的时间段,给tidb server用。那假设server1向pd申请了1-3秒的tso时间,恰好刚申请完,在3秒的时间内,server2 也需要申请tso,pd会返回给server2 一个4-6秒的tso时间。因为两个tidb server的节点事务时间离的很近,但是申请的tso时间确很远,这样事务的时间顺序不就存在问题了么?
2、tidb 聚簇表自增主键使用auto_random来随机生成一个主键数字,已实现数据分布在不同region上,来降低热点分布。但是我理解数据的写入应该是在一个region上,顺序写入,比如一个表的update是在走最后增加一条数据,而不是修改原来的数据,这样的话,我理解数据写入的key有可能会出现无序的情况。那auto_random又是怎么实现数据分布来降低热点的呢,我懵了,可能我update和key顺序上也存在理解上的问题。
请大家帮忙解答解答

5赞

MVCC

很多数据库都会实现多版本并发控制 (MVCC),TiKV 也不例外。设想这样的场景:两个客户端同时去修改一个 Key 的 Value,如果没有数据的多版本控制,就需要对数据上锁,在分布式场景下,可能会带来性能以及死锁问题。TiKV 的 MVCC 实现是通过在 Key 后面添加版本号来实现,简单来说,没有 MVCC 之前,可以把 TiKV 看做这样的:

Key1 -> Value
Key2 -> Value
……
KeyN -> Value

有了 MVCC 之后,TiKV 的 Key 排列是这样的:

Key1_Version3 -> Value
Key1_Version2 -> Value
Key1_Version1 -> Value
……
Key2_Version4 -> Value
Key2_Version3 -> Value
Key2_Version2 -> Value
Key2_Version1 -> Value
……
KeyN_Version2 -> Value
KeyN_Version1 -> Value
……

注意,对于同一个 Key 的多个版本,版本号较大的会被放在前面,版本号小的会被放在后面(见 Key-Value 一节,Key 是有序的排列),这样当用户通过一个 Key + Version 来获取 Value 的时候,可以通过 Key 和 Version 构造出 MVCC 的 Key,也就是 Key_Version。这里的Version就是通过TSO构造

2赞

题主的问题1疑问就是在这里吧,以tso构造version的话,新的version有可能比老的还小

1赞

那是时钟回拨,实际上这个 version 只会越来越大,因为是单调递增,不太可能出现回拨的情况,除非人为。。。

1赞

如果题主问题1的描述是正确的,感觉通过tso构造version会有问题,求解惑,谢谢!

1赞

哪个啊,有几种优化方案,目前tidb 中已经在用了,
1秒中可以生成 多少亿个TSO ,我忘记了,具体的你可以在asktug上搜索。
这样子的生成效率能满足绝大部分的场景了;

然后处理方式:


最早一种是 batch 来获取 TSO
后面结合 future 的方式,异步来实现获取 TSO

最新的,你可以参考这个图:

最后可以参考下这个描述:

1赞

实际上这个 version 只会越来越大

1赞

谢谢,大概明白了,之前理解是有点问题,3秒的时间原来是pd提前分配一个时间窗口,来对tlast进行持久化,保存到etcd中的性能小号。
tidb server申请tso也是批量的,但是是更细粒度的。

tidb-server申请tso是批量的

1赞

会越来越大,时间越来越大