feat: split read request thread pool

[Smityz]

Split read request into 2 threads pools.
get and ttluse one threads pool, and other read requests use another one

Related PR: XiaoMi/rdsn#856
Benchmark: benchmark.pdf

[acelyc111]

@Smityz What's your motivation to do this work?

[Smityz]

@Smityz What's your motivation to do this work?

Slow query tasks like multiget/scan should be separated from the thread pool, otherwise get request will be blocked by queueing up

[neverchanje]

Imo separation of different types of operations into multiple pools doesn't essentially solve the problem... It only mitigates some cases...

Think of a complex workload that consists of huge single key get, and small span of multiget. How do y suppose to adjust the thread pools? Will you assign a set of threads separately for each operation?

[foreverneverer]

Imo separation of different types of operations into multiple pools doesn't essentially solve the problem... It only mitigates some cases...

Think of a complex workload that consists of huge single key get, and small span of multiget. How do y suppose to adjust the thread pools? Will you assign a set of threads separately for each operation?

Yeah, right. Actually we have discussed the problem for different case. However, since the benchmark has showed the improvement, at least it doesn't become worse, we decide apply it and verify its online effect.

scan query and point query is different type for exec time in most case, so seperate them seem to be appropriate in theory.