scheduler: use qps priority with multi priorities in hot region scheduler

[lhy1024]

What problem does this PR solve?

The current hotspot identification mainly uses byte and key dimensions, which are not very fit for load requests with high CPU overhead but low hard disk overhead, we plan to add QPS dimension to better describe the distribution of CPU resources.

What is changed and how it works?

use qps dimension as the first priority in hot region scheduler

Check List

Tests

• Unit test

Release note

use qps dimension  as the first priority in  hot region scheduler

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• Yisaer
• nolouch

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[codecov]

Codecov Report

Merging #3923 (f4c9402) into master (fa0ada7) will decrease coverage by 0.12%.
The diff coverage is 77.10%.

@@            Coverage Diff             @@
##           master    #3923      +/-   ##
==========================================
- Coverage   74.59%   74.47%   -0.13%     
==========================================
  Files         246      246              
  Lines       25037    25059      +22     
==========================================
- Hits        18677    18662      -15     
- Misses       4703     4728      +25     
- Partials     1657     1669      +12     

Flag	Coverage Δ
unittests	74.47% <77.10%> (-0.13%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
server/statistics/hot_peer.go	100.00% <ø> (ø)
server/schedulers/hot_region_config.go	80.76% <40.00%> (-2.24%)	⬇️
server/schedulers/hot_region.go	85.20% <77.14%> (-0.95%)	⬇️
server/schedulers/utils.go	93.23% <100.00%> (+0.06%)	⬆️
server/statistics/hot_peer_cache.go	95.71% <100.00%> (-0.02%)	⬇️
tools/pd-ctl/pdctl/command/scheduler.go	73.19% <100.00%> (+0.08%)	⬆️
pkg/tempurl/tempurl.go	45.00% <0.00%> (-15.00%)	⬇️
server/region_syncer/server.go	83.08% <0.00%> (-5.89%)	⬇️
server/tso/tso.go	57.45% <0.00%> (-4.98%)	⬇️
server/schedule/region_scatterer.go	80.70% <0.00%> (-4.39%)	⬇️
... and 15 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fa0ada7...f4c9402. Read the comment docs.

[rleungx]

I think it's not very elegant. Once we introduce another dimension, we need to add more fields, e.g., thirdPriority, forthPriority.

[nolouch]

+1, maybe directly use the array? but it is also difficutity to add third priority or fourth priority even use the array.

[Yisaer]

we only consider 2 dimension during calculating rank now, so introducing new dimension won't change the logic here.

[lhy1024]

Currently only two dimensions are considered, if a third dimension is introduced, the whole scheduling policy may need to be modified

[Yisaer]

Basically lgtm

[nolouch]

PTAL @HunDunDM @bufferflies

[lhy1024]

/merge

[ti-chi-bot]

@lhy1024: It seems you want to merge this PR, I will help you trigger all the tests:

/run-all-tests

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: f4c9402