Databases 7 min read

Understanding Redis Cluster Slot Mechanism, CRC16 Hashing, and Gossip Heartbeat Protocol

This article explains the three Redis clustering modes, details how Redis Cluster uses 16384 hash slots calculated by CRC16, describes the rationale behind the slot count, and outlines the gossip‑based heartbeat communication and message format between master nodes.

Full-Stack Internet Architecture
Full-Stack Internet Architecture
Full-Stack Internet Architecture
Understanding Redis Cluster Slot Mechanism, CRC16 Hashing, and Gossip Heartbeat Protocol

Redis offers three clustering solutions: master‑slave replication, Sentinel, and Redis Cluster. When a single Redis instance cannot meet massive storage demands, a distributed cluster is adopted.

Redis Cluster partitions data using 16384 slots; each node maintains a subset of slots and the keys mapped to them. Clients can connect to any node; if a node receives a request for a slot it does not own, it returns the address of the correct node, and the client transparently redirects the request.

Slot calculation formula: slot = CRC16(key) % 16384 . Adding, removing, or moving nodes does not make the cluster unavailable because the hash‑slot mechanism allows easy redistribution.

The slot count of 16384 (instead of the maximum 65536 possible from a 16‑bit CRC) is chosen for several reasons:

Heartbeat packets contain the full slot bitmap; 16384 slots require only 2 KB (16384/8) while 65536 slots would need 8 KB, increasing bandwidth usage.

Redis Cluster is unlikely to exceed 1000 master nodes; a larger slot space would waste space without practical benefit.

A 16384‑slot range ensures each master has enough slots even at the upper limit of node count.

The heartbeat message between master nodes follows a gossip protocol. Each node periodically selects peers to exchange ping/pong messages, eventually propagating cluster state to all nodes.

Message format includes a header and body. The header contains a bitmap array representing owned slots:

unsigned char myslots[CLUSTER_SLOTS/8]; // length = 16384/8 = 2048 bytes.

The body carries information about a subset of other nodes (about 1/10 of total nodes), e.g., ~1 KB for ten nodes.

Key points:

Each second, a master sends a number of ping messages calculated as 1 + 10 * num(node.pong_received > cluster_node_timeout/2) .

Using 65536 slots would enlarge ping headers fourfold, wasting bandwidth.

More than 1000 nodes would cause network congestion due to larger heartbeat payloads.

Smaller slot counts improve bitmap compression, reducing heartbeat size.

In summary, Redis Cluster’s 16384‑slot design balances memory usage, network bandwidth, and scalability, making it suitable for typical deployments.

BackendRedisClusterdatabasesSlotgossipCRC16
Full-Stack Internet Architecture
Written by

Full-Stack Internet Architecture

Introducing full-stack Internet architecture technologies centered on Java

0 followers
Reader feedback

How this landed with the community

login 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.