[Bug]: inquiry about ioredis not working properly with redis sharded cluster

Bug description

Are you guys aware of issue with ioredis and sharded cluster that has been present for several years and the issue is still open? Please review this carefully:

Thanks for raising this up! Yeah we currently don't route messages to the right node and also don't subscribe to the right node. Should think about a solution for that.

Is this an issue that might be relevant when using colyseus to scale it horizontally? For example, what kind of memory usage would 1m players have in redis and would cluster be needed?

Steps to reproduce

use redis sharded cluster with ioredis

Environment & Versions

Latest

Context

From redis docs: Sharded Pub/Sub

From Redis 7.0, sharded Pub/Sub is introduced in which shard channels are assigned to slots by the same algorithm used to assign keys to slots. A shard message must be sent to a node that owns the slot the shard channel is hashed to. The cluster makes sure the published shard messages are forwarded to all nodes in the shard, so clients can subscribe to a shard channel by connecting to either the master responsible for the slot, or to any of its replicas. SSUBSCRIBE, SUNSUBSCRIBE and SPUBLISH are used to implement sharded Pub/Sub.

Sharded Pub/Sub helps to scale the usage of Pub/Sub in cluster mode. It restricts the propagation of messages to be within the shard of a cluster. Hence, the amount of data passing through the cluster bus is limited in comparison to global Pub/Sub where each message propagates to each node in the cluster. This allows users to horizontally scale the Pub/Sub usage by adding more shards.

1. Regular PUBLISH/SUBSCRIBE:

// This message gets sent to ALL nodes in the cluster
client.publish('user:123:notifications', 'Hello!')

/*
Flow:
1. Message published
2. Broadcasted to every node in cluster
3. Every subscriber on any node receives it
4. More network traffic & resources used
*/

1. Sharded SPUBLISH/SSUBSCRIBE:

// This message only goes to the specific shard that handles this hash slot
client.spublish('{user:123}:notifications', 'Hello!')

/*
Flow:
1. Message published
2. Redis calculates hash slot from {user:123}
3. Message only sent to node handling that slot
4. Only subscribers on that specific node receive it
5. Less network traffic & more efficient
*/

Visual Comparison:

Regular Pub/Sub:

[Client] --publish--> [Node 1] --broadcast--> [Node 2]
                        |                        |
                        v                        v
                   [Subscribers]            [Subscribers]
                        |                        |
                        v                        v
                   [Node 3] ----------------> [Node 4]
                        |                        |
                        v                        v
                   [Subscribers]            [Subscribers]

Sharded Pub/Sub:

[Client] --spublish--> [Hash Slot Calculation]
                              |
                              v
                    [Only to specific Node]
                              |
                              v
                    [Only local Subscribers]

This is why sharded pub/sub is more efficient when you have:

• Large number of channels
• High message volume
• Cluster deployment
• Need for better scalability

The trade-off is that you need to carefully plan your channel naming using hash tags to ensure related messages go to the same shard.

Proposed solution

Let's switch to node-redis which is maintained and works fully with sharded redis cluster!