Jan 22, 2026

Redis Complete Guide: Installation, Data Types, Persistence, and Clustering

A comprehensive Redis guide covering installation on macOS, Windows, and Docker, all five core data types with commands, RDB/AOF persistence, replication, Sentinel, and Cluster deployment.

Bruce

RedisDatabaseCacheNoSQLMiddleware

AI Guides

2358 Words

2026-01-22

Redis Complete Guide: From Beginner to Production

Redis (Remote Dictionary Server) is an open-source, in-memory key-value store renowned for blazing-fast read/write performance and versatile data structure support. It has become a cornerstone of modern application architectures, powering everything from caching layers to real-time leaderboards. This guide walks you through Redis from the ground up — installation, core data types, persistence strategies, and high-availability deployments.

What Is Redis?

Redis is written in ANSI C and operates primarily in memory, though it supports durable persistence to disk. Unlike simple key-value stores, Redis offers rich data structures — strings, hashes, lists, sets, and sorted sets — each with dedicated commands optimized for specific access patterns.

Key characteristics:

High throughput — Pure in-memory operations deliver 100,000+ QPS on commodity hardware
Rich data structures — String, Hash, List, Set, Sorted Set, and more
Atomic operations — Every command is atomic; transactions are supported via MULTI/EXEC
Durable persistence — RDB snapshots and AOF write-ahead logging
High availability — Built-in replication, Sentinel failover, and native clustering

Common Use Cases

Use Case	How Redis Helps
Caching	Store hot data in memory to offload your primary database
Session storage	Share sessions across distributed application servers
Leaderboards	Sorted Sets provide real-time ranking out of the box
Message queues	Lists support blocking pop operations for simple queuing
Rate limiting / counters	Atomic INCR makes counting requests trivial
Distributed locks	SETNX with expiration enables cross-process mutual exclusion

Installation and Configuration

macOS (Homebrew)

Homebrew is the easiest way to install Redis on macOS:

# Update Homebrew (optional but recommended)
brew update

# Install Redis
brew install redis

Starting the server:

# Option A: Run as a background service (recommended)
brew services start redis

# Check service status
brew services list

# Option B: Run in the foreground (useful for debugging)
redis-server

Verify the installation:

redis-cli ping
# Expected response: PONG

Managing the service:

# Stop Redis
brew services stop redis

# Restart Redis
brew services restart redis

Windows

Redis does not officially ship Windows binaries, but there are several solid options.

Option 1: WSL (Recommended)

Windows Subsystem for Linux runs native Linux Redis with full feature parity:

# 1. Install WSL with Ubuntu
wsl --install

# 2. Install Redis inside WSL
sudo apt update
sudo apt install redis-server

# 3. Start the server
sudo service redis-server start

# 4. Verify
redis-cli ping

Option 2: Windows Port (MSI Installer)

Download the MSI package from tporadowski/redis:

Download Redis-x64-5.0.14.1.msi
Run the installer
Redis registers as a Windows service and starts automatically

Service management via PowerShell:

# Check status
Get-Service redis

# Stop
Stop-Service redis

# Start
Start-Service redis

Option 3: Latest Versions (No MSI)

The redis-windows/redis-windows project provides Redis 6.x, 7.x, and 8.x builds for Windows. Extract the archive and run start.bat.

Docker

Docker gives you the most consistent cross-platform experience:

# Pull the latest image
docker pull redis:latest

# Start a container with persistent storage
docker run -d \
  --name redis \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:latest

# Verify
docker exec -it redis redis-cli ping

With a custom configuration file:

docker run -d \
  --name redis \
  -p 6379:6379 \
  -v /path/to/redis.conf:/usr/local/etc/redis/redis.conf \
  -v redis-data:/data \
  redis:latest redis-server /usr/local/etc/redis/redis.conf

Essential Configuration

Here are the most important settings in redis.conf:

# Bind to localhost only (restrict to specific IPs in production)
bind 127.0.0.1

# Default port
port 6379

# Require authentication (always set this in production)
requirepass your_password

# Memory limit
maxmemory 256mb

# Eviction policy when memory limit is reached
maxmemory-policy allkeys-lru

# RDB snapshot rules
save 900 1      # Snapshot if >= 1 write in 900 seconds
save 300 10     # Snapshot if >= 10 writes in 300 seconds
save 60 10000   # Snapshot if >= 10,000 writes in 60 seconds

# Logging
loglevel notice
logfile "/var/log/redis/redis-server.log"

Core Data Types

Redis five core data types

Redis ships with five primary data types. Each one is backed by purpose-built internal encodings that automatically adapt based on the size and shape of your data.

1. String

The most fundamental type. A single key maps to a single value — binary-safe, up to 512 MB. Strings handle text, integers, serialized objects, and even raw bytes.

# Basic get/set
SET name "Redis"
SET counter 100
GET name

# Set with expiration (seconds)
SET session "abc123" EX 3600

# Set only if the key does not exist (useful for distributed locks)
SETNX lock "1"

# Atomic arithmetic
INCR counter        # 101
DECR counter        # 100
INCRBY counter 10   # 110

# Batch operations (fewer round trips)
MSET k1 "v1" k2 "v2" k3 "v3"
MGET k1 k2 k3

# Append and measure
APPEND name " Database"
GET name      # "Redis Database"
STRLEN name   # 14

Typical uses: caching, counters, distributed locks, session tokens.

2. Hash

A Hash is a collection of field-value pairs attached to a single key — essentially a small dictionary. Compared to serializing an entire object into a String, Hashes let you read and write individual fields without touching the rest.

# Set individual fields
HSET user:1001 name "Alice"
HSET user:1001 age 25
HSET user:1001 email "[email protected]"

# Set multiple fields at once
HMSET user:1002 name "Bob" age 30 email "[email protected]"

# Read fields
HGET user:1001 name
HMGET user:1001 name age
HGETALL user:1001

# Check existence and delete
HEXISTS user:1001 name
HDEL user:1001 email

# Introspect the hash
HKEYS user:1001
HVALS user:1001
HLEN user:1001

# Atomic field increment
HINCRBY user:1001 age 1

Typical uses: user profiles, product details, configuration objects.

3. List

A doubly-linked list that supports push/pop from both ends and range queries. Elements are ordered by insertion time.

# Push from the left
LPUSH queue "task1"
LPUSH queue "task2" "task3"

# Push from the right
RPUSH queue "task4"

# Read all elements (index 0 to -1)
LRANGE queue 0 -1

# Pop from either end
LPOP queue
RPOP queue

# Access by index and measure length
LINDEX queue 0
LLEN queue

# Blocking pop — waits up to 30 seconds for an element
BLPOP queue 30

# Remove specific elements
LREM queue 1 "task1"   # Remove 1 occurrence of "task1"

# Trim to keep only the first 100 elements
LTRIM queue 0 99

Typical uses: message queues, activity feeds, recent-history lists.

4. Set

An unordered collection of unique strings. Sets shine when you need membership tests or set-theoretic operations (intersection, union, difference).

# Add members
SADD tags "redis" "database" "cache"

# List all members
SMEMBERS tags

# Membership check
SISMEMBER tags "redis"

# Cardinality and removal
SCARD tags
SREM tags "cache"

# Random sampling
SRANDMEMBER tags 2
SPOP tags

# Set operations
SADD set1 "a" "b" "c"
SADD set2 "b" "c" "d"

SINTER set1 set2    # {"b", "c"}
SUNION set1 set2    # {"a", "b", "c", "d"}
SDIFF set1 set2     # {"a"}

Typical uses: tagging systems, mutual-friends queries, unique visitor tracking.

5. Sorted Set (ZSet)

Like a Set, but every member carries a floating-point score. Members are always sorted by score (ascending), which makes range queries extremely fast.

# Add members with scores
ZADD leaderboard 100 "player1"
ZADD leaderboard 200 "player2"
ZADD leaderboard 150 "player3"

# Range queries (ascending / descending)
ZRANGE leaderboard 0 -1 WITHSCORES
ZREVRANGE leaderboard 0 -1 WITHSCORES

# Score and rank lookups
ZSCORE leaderboard "player1"
ZRANK leaderboard "player1"       # Ascending rank (0-based)
ZREVRANK leaderboard "player1"    # Descending rank

# Increment a score atomically
ZINCRBY leaderboard 50 "player1"

# Score-range query
ZRANGEBYSCORE leaderboard 100 200

# Remove and count
ZREM leaderboard "player1"
ZCARD leaderboard
ZCOUNT leaderboard 100 200

Typical uses: leaderboards, delayed job queues, priority scheduling.

Persistence

Redis persistence: RDB vs AOF

Because Redis is an in-memory database, it needs a persistence strategy to survive restarts. Redis offers two mechanisms — and a hybrid mode that combines both.

RDB (Snapshotting)

RDB is the default persistence mode. Redis periodically forks a child process that writes a point-in-time snapshot of the entire dataset to a compact binary file.

Trigger methods:

Automatic — Based on save rules in the config
Manual — SAVE (blocks the main thread) or BGSAVE (forks a background process)

Configuration:

# Snapshot rules
save 900 1        # After 900s if >= 1 key changed
save 300 10       # After 300s if >= 10 keys changed
save 60 10000     # After 60s if >= 10,000 keys changed

# Output file
dbfilename dump.rdb
dir /var/lib/redis/

# Compression (disable to save CPU at the cost of disk space)
rdbcompression no

# Checksum verification on load
rdbchecksum yes

Pros: Compact files ideal for backups; fast restores; minimal impact on the main thread.

Cons: Data written after the last snapshot is lost on crash; forking can cause a brief latency spike with large datasets.

AOF (Append Only File)

AOF logs every write command in the order it was received. On restart, Redis replays the log to reconstruct the dataset.

Configuration:

# Enable AOF
appendonly yes

# File name
appendfilename "appendonly.aof"

# Sync policy
appendfsync everysec    # Flush to disk every second (recommended)
# appendfsync always    # Flush after every write (safest, slowest)
# appendfsync no        # Let the OS decide (fastest, least safe)

# Automatic rewrite thresholds
auto-aof-rewrite-percentage 100   # Rewrite when the file doubles in size
auto-aof-rewrite-min-size 64mb    # Only rewrite if the file is >= 64 MB

Pros: At most 1 second of data loss with everysec; human-readable log for debugging.

Cons: Larger file size than RDB; slower restores because commands must be replayed.

Hybrid Persistence (Redis 4.0+)

Hybrid mode writes the full dataset in RDB format at the beginning of the AOF file, then appends subsequent write commands in AOF format. This gives you fast restores and minimal data loss.

# Enable hybrid persistence (default since Redis 5.0)
aof-use-rdb-preamble yes

Choosing a Strategy

Scenario	Recommended Approach
Data loss is acceptable	Disable persistence entirely for maximum speed
A few minutes of data loss is fine	RDB only
Data is critical	Hybrid persistence (RDB + AOF)
Zero data loss required	AOF with `appendfsync always`

High Availability

Replication

Replication is the foundation of Redis high availability. A primary node handles writes, and one or more replica nodes receive an asynchronous copy of the data to serve reads.

Configuring a replica:

# In the replica's redis.conf
replicaof 192.168.1.100 6379

# If the primary requires authentication
masterauth your_master_password

Or at runtime:

REPLICAOF 192.168.1.100 6379

Key points:

The primary handles writes; replicas handle reads (read scaling)
Replication is asynchronous — replicas may lag slightly behind
A single primary can serve multiple replicas

Sentinel (Automatic Failover)

Sentinel adds monitoring and automatic failover on top of standard replication. If the primary goes down, Sentinel promotes a replica and reconfigures the others — no manual intervention required.

Sentinel configuration (sentinel.conf):

# Monitor the primary node; quorum of 2 sentinels must agree it is down
sentinel monitor mymaster 192.168.1.100 6379 2

# Primary password
sentinel auth-pass mymaster your_password

# Consider the primary down after 30 seconds of no response
sentinel down-after-milliseconds mymaster 30000

# Failover timeout
sentinel failover-timeout mymaster 180000

# How many replicas sync simultaneously during failover
sentinel parallel-syncs mymaster 1

Start Sentinel:

redis-sentinel /etc/redis/sentinel.conf

How it works:

Sentinel processes continuously ping the primary and its replicas
When the primary becomes unreachable (confirmed by a quorum), Sentinel triggers a failover
One replica is promoted to primary; the others reconfigure to follow the new primary
Clients are notified of the topology change

Cluster (Sharding + HA)

Redis Cluster architecture

Redis Cluster partitions data across multiple primary nodes and provides built-in failover for each shard. It is the right choice when your dataset outgrows a single server.

How it works:

The keyspace is divided into 16,384 hash slots
Each primary owns a subset of slots
Every primary can have one or more replicas for failover
Clients are redirected to the correct node automatically

Creating a cluster (3 primaries + 3 replicas):

# Each instance needs these settings in redis.conf:
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 5000

# Create the cluster
redis-cli --cluster create \
  192.168.1.101:6379 \
  192.168.1.102:6379 \
  192.168.1.103:6379 \
  192.168.1.104:6379 \
  192.168.1.105:6379 \
  192.168.1.106:6379 \
  --cluster-replicas 1

Connecting to a cluster:

# The -c flag enables cluster-aware redirection
redis-cli -c -h 192.168.1.101 -p 6379

Useful cluster commands:

CLUSTER INFO     # Overall cluster health
CLUSTER NODES    # List all nodes and their roles
CLUSTER SLOTS    # Show slot-to-node mapping

Performance Tuning

Memory Management

# Set a hard memory limit
maxmemory 4gb

# Eviction policy (what happens when the limit is reached)
maxmemory-policy allkeys-lru

# Available policies:
# volatile-lru    — LRU among keys with an expiration set
# allkeys-lru     — LRU among all keys
# volatile-random — Random eviction among keys with an expiration
# allkeys-random  — Random eviction among all keys
# volatile-ttl    — Evict keys closest to expiration
# noeviction      — Return errors on write when memory is full

Connection Tuning

# Maximum simultaneous client connections
maxclients 10000

# Close idle connections after N seconds (0 = never)
timeout 300

# TCP keepalive interval
tcp-keepalive 300

Slow Log

The slow log captures commands that exceed a configurable execution-time threshold — invaluable for finding performance bottlenecks.

# Threshold in microseconds (10 ms)
slowlog-log-slower-than 10000

# Maximum number of entries to retain
slowlog-max-len 128

Querying the slow log:

SLOWLOG GET 10    # Last 10 slow commands
SLOWLOG LEN       # Total entries
SLOWLOG RESET     # Clear the log

Best Practices

Recommendation	Why It Matters
Use structured key names	Prefixes like `user:1001:profile` keep the keyspace organized
Keep values small	Keys under 1 KB, values under 10 KB for optimal performance
Set TTLs on everything you can	Prevents unbounded memory growth
Avoid big keys	Split large Hashes/Lists/Sets into smaller shards
Use pipelines for batch operations	Dramatically reduces round-trip latency
Ban dangerous commands in production	`KEYS *`, `FLUSHALL`, `FLUSHDB` can block or destroy data

Summary

This guide covered the essential Redis knowledge you need to go from installation to production:

Installation — Homebrew on macOS, WSL or Docker on Windows, Docker anywhere
Five data types — String, Hash, List, Set, and Sorted Set each solve distinct problems
Persistence — RDB snapshots for fast recovery, AOF for durability, hybrid mode for both
High availability — Replication for read scaling, Sentinel for automatic failover, Cluster for horizontal sharding

The best way to internalize Redis is to build with it. Start with caching and session storage in a real project, then layer on persistence and replication as your reliability requirements grow.