Databases 9 min read

Why Redis Chooses Hash Slots Over Consistent Hashing

The article explains how Redis Cluster distributes keys using CRC16‑based hash slots instead of traditional consistent hashing, detailing the slot calculation, node addition and removal processes, client redirection, smart client optimizations, and the design reasons behind the fixed 16,384 slot count.

LouZai
LouZai
LouZai
Why Redis Chooses Hash Slots Over Consistent Hashing

Redis Cluster Overview

Redis Cluster is a distributed key‑value store that partitions data across multiple nodes using a fixed number of hash slots (16,384). Each key is processed with a CRC16 checksum, the result is taken modulo 16384, and the resulting slot determines the owning node.

Hash Slots vs. Consistent Hashing

Consistent hashing maps keys onto a 2^32 ring and uses virtual nodes to balance load, while Redis hash slots first compute a 16‑bit CRC16 value for the key and then take the modulo 16384 to select a slot. Both aim for even data distribution, but Redis adopts the slot approach for operational flexibility.

Adding a Node

When a new node D is added, the cluster rebalances by moving a portion of slots from existing nodes A, B, and C to D. After redistribution each node holds roughly 4096 slots (16384/4). Administrators can also use the cluster addslots command to assign a custom number of slots to nodes with higher performance.

Removing a Node

If node C is removed, the remaining nodes A and B automatically recalculate slot ownership, ending up with 8192 slots each (16384/2). The cluster migrates the data belonging to the removed slots to the surviving nodes.

Client Access Flow

A client may connect to any cluster node. It first checks whether the key’s slot is owned by the contacted node. If not, the node returns a MOVED redirection containing the target node’s address, and the client retries the command on the correct node.

Smart Client Optimization

Most Redis client libraries implement a “smart client” that maintains a local slot‑to‑node map, eliminating the need for MOVED redirections on every request. The client initializes this map by querying a seed node and updates it as the cluster topology changes.

Why Redis Uses Hash Slots Instead of Consistent Hashing

During scaling, Redis can reassign whole slots to new servers, which is simpler than recomputing key hashes for each added node as required by consistent hashing.

Data migration is straightforward: moving an entire slot transfers all its keys at once, avoiding per‑key calculations.

Slot allocation can be weighted; more powerful nodes can be given a larger number of slots, while weaker nodes receive fewer.

Why the Slot Count Is 16,384

The slot bitmap occupies only 2 KB (16384 bits), keeping heartbeat messages lightweight; a larger space (e.g., 65 536 slots) would increase overhead to 8 KB.

Redis clusters rarely exceed 1,000 master nodes, so 16 384 slots provide ample granularity for load balancing.

With up to 1,000 nodes, each node still receives enough slots to distribute data evenly.

These design choices explain why Redis adopts hash slots and why the specific slot count of 16,384 was selected.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

ScalabilityRedisClusterConsistent HashingHash SlotsCRC16
LouZai
Written by

LouZai

10 years of front‑line experience at leading firms (Xiaomi, Baidu, Meituan) in development, architecture, and management; discusses technology and life.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.