The problem/use-case that the feature addresses

When a cluster client has subscribed to topology changes, slot mappings are pushed to the client as soon as a slot is moved. This let's the client avoid getting MOVED redirects and eliminates the need to poll using CLUSTER SLOTS.

Description of the feature

Usage scenario

1. Client subscribes to slot changes using CLUSTER SUBSCRIBE SLOTS (returns OK).

2. Whenever a slot is migrated, the new slot owner is pushed to the client in an out-of-band message where the relevant part has the same structure as one row in a CLUSTER SLOTS reply.

   1) "cluster"
   2) "slots"
   3) 1) (integer) 5461
      2) (integer) 5461
      3) 1) "127.0.0.1"
         2) (integer) 30002
         3) "c9d93d9f2c0c524ff34cc11838c2003d8c29e013"
         4) 1) hostname
            2) "host-3.redis.example.com"
      4) 1) "127.0.0.1"
         2) (integer) 30005
         3) "faadb3eb99009de4ab72ad6b6ed87634c7ee410f"
         4) 1) hostname
            2) "host-4.redis.example.com"
   
   

3. The client updates it's internal slot mapping tables.

Implementation ideas

• A separate list of subscribed clients is stored in the cluster struct.
• Whenever a node becomes aware of a change, either from the cluster bus or from a SETSLOT ... NODE command, it is pushed to clients.

Alternatives you've considered

• Alternative to CLUSTER SUBSCRIBE SLOTS:

  • Clients use SUBSCRIBE to a magic channel such as __cluster-slots__. This is similar to how client-side caching and keyspace notifications work and is intuitive in both RESP2 and RESP3 modes.

• Alternative to pushing a CLUSTER SLOT row:

  • The push message can contain only one slot number and the master's "host:port", i.e. the same info as in a MOVED redirect. Pros: Less data pushed. Cons: Changes in replicas would not be pushed.

• Support RESP2?

  • Use a second connection, like client-side caching? (too complex)
  • Only supporting RESP3 is simpler. We can require RESP3 and encourage clients to use it.

• Unsubscribe?

  • It's not necessary. The subscription can be active for the life time of the connection.
  • Can be added later.

Additional information

This is "RESPV3 topology updates" in #8948.