Redis Cluster shards data across multiple nodes using a concept called hash slots.
Let’s see this in action. Imagine we have a Redis Cluster with three master nodes: node1:7000, node2:7000, and node3:7000.
# Example: Setting a key in Redis Cluster
redis-cli -c -p 7000
127.0.0.1:7000> SET mykey "myvalue"
-> Redirected to slot [866] located at 127.0.0.1:7001
OK
127.0.0.1:7001> GET mykey
"myvalue"
# Example: Setting another key
127.0.0.1:7000> SET anotherkey "anothervalue"
-> Redirected to slot [12345] located at 127.0.0.1:7002
OK
127.0.0.1:7002> GET anotherkey
"anothervalue"
Notice the -> Redirected to slot [...] located at ... messages. This is Redis Cluster figuring out which node is responsible for a given key.
Here’s how it works: Redis Cluster divides its entire keyspace into 16384 hash slots. When you set a key, Redis calculates a hash of the key itself. This hash value, modulo 16384, determines which hash slot the key belongs to.
The formula is hash_slot = HASH(key) % 16384.
The HASH function used by Redis Cluster is typically CRC16. So, for mykey, the calculation might look like: CRC16("mykey") % 16384. If CRC16("mykey") results in, say, 866, then mykey is assigned to slot 866.
Each master node in the cluster is responsible for a specific range of these hash slots. When a client connects to any node in the cluster and tries to access a key, that node first calculates the key’s hash slot. It then checks its own configuration to see if it’s responsible for that slot.
If the node is responsible for the slot, it handles the request directly. If it’s not responsible, it replies to the client with a MOVED or ASK redirection, telling the client which node is responsible for that slot. The client then connects to the correct node and retries the command.
The distribution of these 16384 hash slots across the available master nodes is the core of Redis Cluster’s sharding. When you add or remove nodes, the cluster rebalances these slots. For example, if you add a new master node, some slots will be migrated from existing nodes to the new one to ensure a relatively even distribution.
This slot-based sharding allows Redis Cluster to:
- Scale horizontally: By adding more master nodes, you can distribute more slots and therefore more data and load.
- Achieve High Availability: Each master node can have one or more replica nodes. If a master node fails, one of its replicas can be promoted to take over its hash slots, ensuring data availability.
- Distribute Load: Commands for keys belonging to different slots will be spread across different master nodes, preventing any single node from becoming a bottleneck.
The redis-cli -c option is crucial for interacting with a cluster. It automatically handles the MOVED and ASK redirections, making it appear as if you’re interacting with a single Redis instance, even though the data is sharded.
The actual assignment of hash slots to nodes isn’t static. When nodes join or leave the cluster, or during manual rebalancing, the cluster state is updated. You can inspect this state using CLUSTER SLOTS.
# Example: Checking cluster slots
redis-cli -p 7000 CLUSTER SLOTS
1) 1) 0) 8191
2) 127.0.0.1
3) 7000
3) 1) 127.0.0.1
2) 7001
2) 1) 8192
2) 127.0.0.1
3) 7002
3) 1) 127.0.0.1
2) 7003
3) 1) 12288
2) 127.0.0.1
3) 7004
3) 1) 127.0.0.1
2) 7005
This output shows which ranges of hash slots are served by which master node (and its replicas). In this example, slots 0-8191 are served by node 127.0.0.1:7000 (with replica 7001), slots 8192-12287 by 127.0.0.1:7002 (with replica 7003), and slots 12288-16383 by 127.0.0.1:7004 (with replica 7005).
A common pitfall is using keys that aren’t compatible with slot-based sharding, like keys that use multiple keys in a single command without a hash tag. For example, MSET key1 value1 key2 value2 would fail if key1 and key2 fall into different slots. Redis Cluster resolves this by requiring that all keys in a multi-key operation must belong to the same hash slot. This is achieved using hash tags: MSET {mykey_part1}value1 {mykey_part1}value2. The curly braces tell Redis to hash only the part inside them, ensuring both keys hash to the same slot.
The number of hash slots (16384) is fixed and cannot be changed. This is a design choice for simplicity and to ensure consistent behavior across all Redis Cluster instances.
The underlying mechanism for distributing slots is a gossip protocol where nodes exchange information about cluster state, including slot assignments. This allows the cluster to dynamically adapt to changes.
When a client issues a command involving multiple keys, such as MGET or DEL, Redis Cluster needs to ensure all those keys map to the same hash slot. If they don’t, the command will fail. This is where hash tags become essential. By enclosing a part of the key name in curly braces, like {user:1000}:profile, you force Redis to use only user:1000 for the hash slot calculation, ensuring that operations on keys related to user:1000 will always target the same node.
Understanding how hash slots are calculated and distributed is key to designing effective Redis Cluster schemas and troubleshooting performance issues.
The next step in understanding Redis Cluster is often diving into replication and failover mechanisms.