Distributed Caching: Redis Cluster vs Memcached

A single Redis server is bounded by single-core CPU execution and single-node physical RAM limits (typically 32GB to 64GB). To scale beyond these boundaries to terabytes of cache memory and millions of operations per second, Redis Cluster distributes data across a horizontally scalable sharded cluster.

Unlike classical distributed hash rings, Redis Cluster uses 16,384 fixed Hash Slots:

The Slot Mapping Formula:

Slot = CRC16(key) \pmod{16384}

1. Slot Allocation: The 16,384 slots are divided among active master nodes (e.g., in a 3-master cluster: Master 1 holds slots 0-5460, Master 2 holds 5461-10922, Master 3 holds 10923-16383).
2. Client-Side Smart Routing: Redis smart clients (e.g., Jedis, ioredis, redis-py) cache the cluster slot topology map in memory. When executing GET user:8492, the client calculates CRC16("user:8492") \pmod{16384} = 7210, and connects directly to Master 2 in a single network hop.
3. -MOVED Redirects: If a slot is migrated during cluster rebalancing, the old node returns a -MOVED 7210 10.0.1.2:6379 error, instructing the client to update its cached topology map and retry.

Redis Hash Tags: Multi-Key Atomicity

By default, Redis operations involving multiple keys (MGET, MSET, Lua scripts, transactions) require all keys to reside in the same hash slot.

• Hash Tag Syntax: Enclosing part of a key in curly braces {...} forces Redis to hash only the substring inside the braces:
  • Key 1: {user:101}:profile → hashes "user:101"
  • Key 2: {user:101}:orders → hashes "user:101"
  • Both keys hash to the exact same slot, enabling atomic transactions and joins on the same Redis shard!