【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
使用read_ts读取，存在比read_ts更小的写事务提交成功吗
有遇到的具体一点场景或者案例啥的吗？
楼主你描述的是 Stale Read 场景下的问题吗？
如果是，那么 Stale Read 是一种读取历史数据版本的机制，读取的是已经提交的历史数据版本，不会读取到最新的提交数据。
没看明白
如果某个写事务的 commit_ts 小于当前节点的 read_ts，则不会被读取到。但是，在集群中可能存在不同节点的时间戳不完全一致的情况，可能会出现某些事务的 commit_ts 比某些节点的 read_ts 更小的情况。
read_ts是哪里看到的?文档中没找到。
读取时候的时间戳肯定是大于提交时的时间戳的，不然就是脏读。
Stale Read 是一种读取历史数据版本的机制，读取 TiDB 中存储的历史数据版本。通过 Stale Read 功能，你能从指定时间点或时间范围内读取对应的历史数据，从而避免数据同步带来延迟。当使用 Stale Read 时，TiDB 默认会随机选择一个副本来读取数据，因此能利用所有副本。
链接：https://docs.pingcap.com/zh/search?type=tidb&version=stable&q=系统变量
在使用Stale Read读取数据时，TiDB会对Read ts做检查，保证大于Region 的Safe ts，在Leader上，safe ts随着Resolved TS推进而推进，Follower上的Safe ts时随着CheckLeader RPC 从 leader 同步过来的，这样等Follower apply到Leader的index时，就可以推进Safe ts到Leader的Leader的Safe ts，所以Read ts>Safe ts>Resolved ts>后续的Commit ts
时间戳不都是leader PD给的么？应该不会存在不同节点不完全一致的情况么？
不清楚是否叫Stale Read.
比如现在有个key(commit_ts=10) = v10, 现在有个新的写事务获取了commit_ts=20, 另外一个并发读事务获取了ts=30, 当使用ts=30读取了key(commit_ts=10)后，commit_ts=20事务才开始执行，生成key(commit_ts=20) = v20, 按理ts=30的读事务应该读取v20
并发的两个事务，分别为写事务和读事务，读事务的ts更大，由于并发执行存在读事务执行后写事务才开始执行。读事务读取了此写事务之前的版本，按理读事务应该读取此写事务完成后的版本。
1.不管是读事务还是写事务，都是由PD Leader统一分配严格递增的事务ID，包括事务开始时间和事务结束时间，按照你的描述就是你所说的ts 。不同并发的访问请求，事务开始的时间一定有先后顺序。
2.快照隔离级别永远只会读到在本事务开始之前已经完成提交的事务结果，未提交的事务不会被访问。所以，只要事务开始时间为20的写事务没有在30之前提交，那么事务开始时间为30的读事务就不会访问到它的数据。它只会读到v10就完成了读事务过程。
建议你再去看看官方关于事务描述相关的文档。
不需要引入并发，你说的是这个意思么？读事务读到的是0，写事务写的是1？
字段A值为0，00:01写事务开始，00:02读事务开始，00:03读事务结束，00:04写事务修改字段A值为1，00:05写事务结束。
如果是加上事务的话，我理解的是，00:03读事务不会结束，直到00:05写事务结束后，读事务才会结束，读到的是1。
合着你不是在说Stale Read啊 
嗯。快照读ts=30会更新tikv节点的MaxTs, 新的提交事务的ts必须大于等于MaxTs+1，因此ts=20的写事务会被阻止提交。
写不阻塞读，读不阻塞写。
写写才会有冲突。