ReadIndex service may got duplicate ctx

[nolouch]

Bug Report

What version of TiKV are you using?
release3.0 rc2

Problems

1. The ctx of pending reading is independently produced by tikv itself, it may same in leader and follower at the same time, the ReadIndex request will conflict and may lose one.
2. If we use follwer_id in ctx, it will solve problem 1, but if follower restart will also produce the same ctx.
3. advance the pending reads may need to iterate all pending reads, which is slowly. likely get the order of ctx in follower from ready is 1 2 4 5 6 7 8 9 3.

[overvenus]

How about combining peer id and current unix timestamp? It does the best effort and should cover for most cases.

[nolouch]

cc @5kbpers

[5kbpers]

How about combining peer id and current unix timestamp? It does the best effort and should cover for most cases.

Great idea. I think we could get a monotonic clock time, combine with peer_id as the first id, then increase it to allocate the following ids.

[BusyJay]

Monotonic clock time is not reliable. It's not guaranteed to be increased monotonically between booting.

[5kbpers]

Monotonic clock time is not reliable. It's not guaranteed to be increased monotonically between booting.

Yes, we can use SystemTime too, but I'm worried about it would be not reliable when the process restart.

[BusyJay]

Why not use UUID?

[5kbpers]

UUID can not be sorted :(

[5kbpers]

Seems it is not required to be sorted (get it after reading the code again), UUID is a good idea :)

[Hoverbear]

Hi folks seems this is fixed by #5213. I'm closing this but feel free to reopen.