redis-clustering by redis

Redis Clustering

Guidance for designing keys and routing reads in a sharded Redis Cluster (and in standalone primary/replica replication). Covers the two failure modes that bite most new cluster users: CROSSSLOT errors on multi-key operations, and overloading primaries with read traffic.

When to apply

Designing keys for a Redis Cluster deployment.
Debugging a CROSSSLOT error on MGET, SDIFF, transactions, or pipelines.
Implementing transactions / Lua scripts that touch multiple keys.
Scaling out read traffic without adding shards.

1. Hash tags for multi-key operations

Redis Cluster distributes keys across 16,384 slots by hashing the key name. Any command that touches multiple keys (MGET, SDIFF, SUNIONSTORE, transactions, pipelines, Lua scripts with multiple KEYS[]) requires all keys to live on the same slot — otherwise the server returns a CROSSSLOT error.

Hash tags force this: the part between { and } is the only thing hashed for slot assignment, so two keys sharing a hash tag always land together.

# Same slot — multi-key ops work
redis.set("{user:1001}:profile",  "...")
redis.set("{user:1001}:settings", "...")
redis.lmove("{user:1001}:pending", "{user:1001}:processed", "LEFT", "RIGHT")

# Different keys, no hash tag — CROSSSLOT on multi-key commands in cluster mode
redis.set("user:1001:profile",  "...")
redis.set("user:1001:settings", "...")
pipe = redis.pipeline()
pipe.get("user:1001:profile")
pipe.get("user:1001:settings")
pipe.execute()  # CROSSSLOT error in cluster

Rules of thumb:

Use a tag scoped to the meaningful entity, e.g. {user:1001}. Avoid bare {1001} — unrelated namespaces (purchase:{1001}, employee:{1001}) would all collide on the same slot.
Only tag where you actually need multi-key ops. Tagging everything creates hotspots and defeats the point of sharding.
A single-key command on a hash-tagged key works fine, so adding tags later is incremental — but renaming keys in production is painful, so plan tagging up front for entities you'll group.

See references/hash-tags.md.

2. Read replicas for read-heavy workloads

If reads dominate writes, route them to replicas to free primary capacity. Works both in Redis Cluster (each shard has 1+ replica) and in standalone primary/replica replication.

# Redis Cluster: enable replica reads on the client
from redis.cluster import RedisCluster

rc = RedisCluster(host="localhost", port=6379, read_from_replicas=True)
rc.set("key", "value")     # → primary
value = rc.get("key")       # → may be served by a replica

For non-cluster setups, point two clients at the right nodes:

primary = Redis(host="primary-host", port=6379)
replica = Redis(host="replica-host", port=6379)
primary.set("key", "value")
value = replica.get("key")

The trade-off is consistency: replicas are eventually consistent. Don't read your own writes from a replica; don't use replica reads for anything that requires strict freshness (financial balances, idempotency state). Good fits: cache layers, analytics, dashboards, recommendation feeds.

See references/read-replicas.md.

References

Third-party checks

No alerts1mo3 checks · Risk SAFE

Gen Agent Trust Hub1mo
This skill provides educational guidance and code examples for working with Redis Clusters, focusing on hash tags for multi-key operations and scaling reads using replicas. It contains only documentation and standard library usage examples.
Socket1mo
No alerts
Snyk1mo
Risk: LOW · No issues

What it does

Fixes CROSSSLOT errors and scaling bottlenecks in sharded Redis Cluster by using hash tags to co-locate multi-key operations and routing reads to replicas. Targets deployments using MGET, transactions, pipelines, or Lua scripts across multiple keys, and read-heavy workloads that need to offload primary shards.

Generated from the current SKILL.md.

Frequently asked

How do I fix a CROSSSLOT error on MGET or pipeline operations in Redis Cluster?

Use hash tags to force multi-key operations onto the same slot. Wrap the entity identifier in curly braces, e.g. `{user:1001}:profile` and `{user:1001}:settings`, so both keys hash to the same slot.

Can I route reads to replicas to reduce primary load?

Yes. In Redis Cluster, set `read_from_replicas=True` on the client. In standalone replication, point read operations to the replica node directly. Replicas are eventually consistent, so only use this for non-critical reads like caches or dashboards.

What happens if I hash-tag unrelated namespaces together?

They will collide on the same slot, creating a hotspot that defeats the purpose of sharding. Use a tag scoped to a single meaningful entity (e.g. `{user:1001}`) rather than a bare identifier.

Do I need to hash-tag every key in my application?

No. Only tag keys when you actually need them in multi-key operations (transactions, pipelines, Lua scripts). Single-key commands work fine without tags, and universal tagging creates unnecessary hotspots.

Generated from the current SKILL.md. These answers refresh after source changes.

/redis-clustering

SKILL.md