Cluster & Sentinel

# ===== Why cluster =====
# - Scale beyond a single server's memory
# - Automatic sharding across nodes (no single master for all keys)
# - Built-in failover via replication

# ===== Slot model =====
# - 16384 slots across all keys (hash slot = CRC16(key) % 16384)
# - Each node owns a CONTIGUOUS range of slots
# - Clients route to the correct node (or get redirected MOVED / ASK)

# ===== Topology =====
# Minimum production: 3 masters + 3 replicas = 6 nodes
# Each master owns ~5461 slots
# Each replica mirrors one master; promoted on master failure

# ===== Create a cluster (Redis 5+) =====
# Start 6 nodes on different ports with cluster-enabled yes
# Then:
redis-cli --cluster create \
  127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1

# ===== Connect (client) =====
# Use a cluster-aware client:
import { createCluster } from 'redis';
const client = createCluster({
  rootNodes: [{ url: 'redis://127.0.0.1:7000' }],
});
await client.connect();
await client.set('user:1', 'Alex');

# ===== Hash tags (force keys onto the same slot) =====
# Multi-key operations (transactions, scripts, MSET) require all keys in the SAME slot.
# Wrap part of the key in {...} to make only that part hash:
SET {user:1}:profile '...'
SET {user:1}:settings '...'
# Both keys land on the same slot; multi-key ops work.

# ===== Operations =====
# Add a node:
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000

# Rebalance slots:
redis-cli --cluster reshard 127.0.0.1:7000 --cluster-from <id> --cluster-to <id> --cluster-slots 1000

# Remove a node:
redis-cli --cluster del-node 127.0.0.1:7000 <node-id>

# Check health:
redis-cli --cluster check 127.0.0.1:7000
redis-cli --cluster info 127.0.0.1:7000

# ===== Failover =====
# On master failure: replicas detect; one is promoted by gossip protocol.
# Quorum: needs MAJORITY of masters available (so 2 of 3 minimum).
# Client receives MOVED redirects until topology stabilises.

# ===== Constraints =====
# - Pipelines + transactions only work within a single slot
# - SUBSCRIBE / PSUBSCRIBE not cluster-aware in all clients
# - Lua scripts: KEYS must hash to the same slot
# - SCAN walks one node at a time (per-node cursor)

# ===== Persistence + backup =====
# Each node has its own RDB / AOF.
# Back up each master independently (or use Sentinel-based + cluster combination).

# ===== Alternatives =====
# - Redis Sentinel: HA without sharding (one logical master)
# - Redis Cloud / ElastiCache: managed cluster
# - Twemproxy / nutcracker: client-side proxy sharding (legacy)
# - KeyDB / Dragonfly: alternative implementations with different cluster stories

# ===== Patterns to internalise =====
# - Hash tags whenever multi-key ops matter
# - 3-master minimum; replicas per master
# - Use cluster-aware client; do not implement your own slot routing
# - Plan resharding windows (slot moves are throttled but visible)

# ===== Pitfalls =====
# - Multi-key ops without hash tags -> CROSSSLOT error
# - Treating cluster as a transparent single Redis (clients differ)
# - Backup only one node thinking it covers all data
# - Network partition splitting the cluster -> minority side stops accepting writes

# Sharded across multiple nodes (hash slots 0-16383).
CLUSTER NODES
CLUSTER SLOTS
# Sentinel: HA for non-clustered setups