tikv: use timestamp from TSO instead of MaxVersion in point get retry

[sticnarf]

What problem does this PR solve?

We use MaxVersion to read when doing an auto-commit point select. Such reads can be blocked by any secondary locks or async-commit locks for linearizability.

Before this PR, we try to resolve the lock and backoff before retry. However, these operations can be unnecessary. And in the worst cases, it is possible that the reader keeps meeting different locks after backoff, which increases latency a lot.

What is changed and how it works?

In this PR, before doing a point get with max version, we get a timestamp from the TSO asynchronously. If the point get meets a lock, we use the timestamp from the TSO to retry. It does not add latency if point get does not meet a lock while improving the worst cases.

Check List

Tests

• Unit test
• Manual test (add detailed scripts or steps below)

Run two sysbench test concurrently:

1. update index with zipfian exp=2, 256 threads (with async commit enabled)
2. point select with zipfian exp=2, 64 threads

So the point select will read the lock very often. Measure the QPS of point select:

Master: 5032.14
This PR: 8809.72

Release note

• Use TSO timestamp in auto-commit point get retries.

[youjiali1995]

LGTM

[youjiali1995]

Run two sysbench test concurrently:
update index with zipfian exp=2, 256 threads
point select with zipfian exp=2, 64 threads
So the point select will read the lock very often. Measure the QPS of point select:
Master: 5032.14
This PR: 8809.72

Is async-commit on? The reason why async commit has some regression using point get in high-conflict scenarios is it's more likely to be blocked by memory locks because they're written faster in memory than the raft store?

[sticnarf]

Run two sysbench test concurrently:
update index with zipfian exp=2, 256 threads
point select with zipfian exp=2, 64 threads
So the point select will read the lock very often. Measure the QPS of point select:
Master: 5032.14
This PR: 8809.72

Is async-commit on? The reason why async commit has some regression using point get in high-conflict scenarios is it's more likely to be blocked by memory locks because they're written faster in memory than the raft store?

Yes. This PR mitigates one of the regression causes. And my another PR tikv/tikv#9625 deals with the other one you mentioned

[nrc]

lgtm

[youjiali1995]

/merge

[ti-srebot]

Your auto merge job has been accepted, waiting for:

• 22833

[ti-srebot]

/run-all-tests