Redis Introduce CLUSTER SLOT-STATS command, to query slot level metrics for Redis cluster

This issue is created to de-couple the CLUSTER SLOT-STATS implementation from the on-going discussion in slot level memory metrics in Introduce slot level metrics to Redis cluster #10472.

What are we introducing

High level changes

CLUSTER SLOT-STATS command will be introduced. This command will be invoked by Redis cluster users to obtain detailed slot usage statistics.

For its first iteration, the command will support key_count per-slot. cpu_usage will be tackled as a follow-up to the merger of the current issue. memory_usage merger is contingent based on the discussion result of Introduce slot level metrics to Redis cluster #10472.

Low level changes

This issue covers the following implementations; - CLUSTER SLOT-STATS along with its mutually exclusive arguments; - SLOTS slot [slot] - SLOTSRANGE start-slot end-slot [start-slot end-slot] - ORDERBY column [LIMIT limit] [ASC | DESC] - key_count - respective .tcl integration tests.

Below is a sample response.

127.0.0.1:6379> CLUSTER SLOT-STATS SLOTS 1 10 100
1) (integer) 1
2) 1) "key_count"
   2) (integer) 0
3) (integer) 10
4) 1) "key_count"
   2) (integer) 0
5) (integer) 100
6) 1) "key_count"
   2) (integer) 0

127.0.0.1:6379> CLUSTER SLOT-STATS ORDERBY KEY_COUNT LIMIT 2 DESC
1) (integer) 16381
2) 1) "key_count"
   2) (integer) 1
3) (integer) 0
4) 1) "key_count"
   2) (integer) 0

Implementation details

Based on the most recent update from the previous thread.

1. Rename to `CLUSTER SLOT-STATS`

We shouldn't include GET prefix when the command is clearly a get. Following identical command standard to MEMORY STATS and MEMORY MALLOC-STATS.

2. Mutual exclusivity of sub-arguments

Option 1. Mutually inclusive

CLUSTER SLOT-STATS
[SLOTS slots [slots ...]]
[SLOTSRANGE start-slot end-slot [start-slot end-slot ...]]
[ORDERBY column [LIMIT limit] [ASC|DESC]]

Pros: Highly flexible. Users can call the commands in various ways.
Cons: Documentation and implementation will look dirty. CLIENT KILL is a good example raised by Oran. Do we really see users running various combinations? it's excessively free and complex.

[Preferred] Option 2. Mutually exclusive, notice the | separator

CLUSTER SLOT-STATS
[SLOTS slots [slots ...]]|
[SLOTSRANGE start-slot end-slot [start-slot end-slot ...]]|
[ORDERBY column [LIMIT limit] [ASC|DESC]]

Pros: Readable and easier to maintain.
Cons: Lack of high flexibility.

Generally, I don't see much use-case in using all sub-arguments at the same time.

If you'd like to ORDERBY to identify hot slots, why wouldn't you want to do it across the entire shard? Vice versa, if you are querying for specific range of slots, you probably wouldn't rank them through ORDERBY, you will only be locating local maxima and minima.

Comment From: madolson

I'm still not convinced we need both SLOTS and SLOTSRANGE. I would prefer just to have SLOTSRANGE for now. It's a bit more verbose if you need to select an individual slot, but I think the default behavior will be for large ranges.

Comment From: kyle-yh-kim

Agreed. As I've already implemented the argument, the 1st revision will contain SLOTS argument. However, if no further concerns are raised, I will have the SLOTS removed for 2nd revision and on-wards.