Redis Performance Testing and Cluster Slot Mechanism Overview

Performance testing: The redis-benchmark command is used to evaluate Redis performance; tests show that a single node generally outperforms a clustered setup.

Cluster principle: Redis Cluster does not use traditional consistent hashing; instead it adopts a hash‑slot concept to simplify data distribution and node placement.

Two concepts underlie hash slots: (1) the hash algorithm – Redis Cluster uses the CRC16 algorithm rather than a simple hash() function, and (2) the slot allocation rules that define how keys map to slots.

Slot migration and assignment are not automatic; administrators must manually configure them. High availability in Redis Cluster relies on master‑slave replication and automatic failover.

16384 slots: Unlike a single‑instance Redis that has 16 databases (0‑15), a cluster divides the keyspace into 16,384 slots, with each node responsible for a subset of these slots, storing slot information locally.

Slot locating algorithm: By default, Redis Cluster hashes a key with CRC16 and takes the result modulo 16384 to determine the slot. The calculation is expressed as hash_slot = CRC16(key) mod 16384 .

Why 16384 slots? Although CRC16 can produce 65,535 values, using 16,384 slots keeps the slot state small (about 2 KB) compared to a larger number which would require more memory (around 8 KB).

Cluster scale design considerations: The cluster can support up to 1,000 shards; 16,384 slots provide a balanced distribution, ensuring each shard receives a reasonable number of slots even at maximum scale.

Two practical issues arise: (1) the need to transfer the full slot state in distributed scenarios, and (2) compression is rarely feasible because each shard handles many slots, making reduction difficult.

If this article helped you, please like, watch, and share—it greatly supports my continued creation of quality content. 🙏🏻