Redis Complete Guide: Commands, Data Types & Caching Patterns

Published February 12, 2026 · 30 min read

Redis is an in-memory data structure store used as a database, cache, message broker, and streaming engine. It stores data in RAM, delivering sub-millisecond response times that traditional disk-based databases cannot match. Every major web application — from Twitter and GitHub to Stack Overflow and Pinterest — uses Redis for caching, session management, real-time analytics, or job queues.

This guide covers Redis from fundamentals through production deployment: every data type, the commands you will use daily, persistence options, caching patterns, client libraries for Python and Node.js, and clustering for high availability.

1. What is Redis and Use Cases

Redis (Remote Dictionary Server) is an open-source, in-memory key-value store. Unlike traditional databases that read from disk, Redis keeps all data in RAM, making reads and writes extraordinarily fast — typically under one millisecond. Redis supports rich data structures beyond simple strings, making it far more versatile than a plain key-value cache.

Common use cases:

• Caching — store frequently accessed database query results, API responses, or rendered HTML fragments to reduce load on your primary database
• Session storage — store user sessions in Redis so they persist across application restarts and work in load-balanced environments
• Job queues — use lists as FIFO queues for background tasks (Sidekiq, Celery, BullMQ all use Redis)
• Pub/Sub messaging — broadcast real-time messages to multiple subscribers for chat, notifications, and live updates
• Rate limiting — use INCR with EXPIRE to count and limit API requests per user within a time window
• Leaderboards — sorted sets maintain rankings with O(log N) insertions and instant range queries
• Real-time analytics — count page views, track unique visitors with HyperLogLog, or manage time-series data with Streams

2. Installation and Setup

Install on Linux (Ubuntu/Debian)

# Install from the official Redis repository
sudo apt update && sudo apt install redis-server

# Start Redis and enable on boot
sudo systemctl start redis-server
sudo systemctl enable redis-server

# Verify it is running
redis-cli ping
# Output: PONG

Install with Docker

# Quick start with Docker
docker run -d --name redis -p 6379:6379 redis:7-alpine

# With persistence and a memory limit
docker run -d --name redis -p 6379:6379 \
  -v redis-data:/data \
  redis:7-alpine redis-server \
  --maxmemory 256mb --maxmemory-policy allkeys-lru --appendonly yes

Connect with redis-cli

# Connect to local instance
redis-cli

# Connect to a remote instance with auth
redis-cli -h 192.168.1.100 -p 6379 -a yourpassword

# Test the connection
127.0.0.1:6379> PING
PONG
127.0.0.1:6379> SET greeting "Hello, Redis!"
OK
127.0.0.1:6379> GET greeting
"Hello, Redis!"

3. Data Types Overview

Redis provides six core data types, each optimized for specific use cases:

• Strings — binary-safe strings up to 512 MB. The simplest type: keys map to values. Also used for integers and floats with atomic increment/decrement.
• Lists — ordered collections of strings, implemented as linked lists. Fast push/pop from both ends. Ideal for queues and recent items.
• Sets — unordered collections of unique strings. Support intersection, union, and difference. Use for tags, unique visitors, and membership tests.
• Sorted Sets — sets where each member has a floating-point score. Members ordered by score. Perfect for leaderboards and priority queues.
• Hashes — maps of field-value pairs, like a miniature object or row. Use for user profiles, product details, or any structured record.
• Streams — append-only log data structures for event sourcing and message queues. Support consumer groups for reliable message processing.

4. Key Commands

These commands work on keys regardless of the underlying data type:

# SET and GET: the fundamental operations
SET user:1:name "Alice"         # set a key
GET user:1:name                 # get a key -> "Alice"

# DEL: delete one or more keys
DEL user:1:name                 # returns number of keys deleted
DEL key1 key2 key3              # delete multiple keys at once

# EXISTS: check if a key exists (returns 1 or 0)
EXISTS user:1:name              # 1 if exists, 0 if not

# EXPIRE and TTL: set and check key expiration
SET session:abc123 "user_data"
EXPIRE session:abc123 3600      # expire in 3600 seconds (1 hour)
TTL session:abc123              # seconds remaining (-1 = no expiry, -2 = gone)

# SET with expiry in one command
SET session:abc123 "user_data" EX 3600    # EX = seconds
SET token:xyz "value" PX 30000           # PX = milliseconds

# PERSIST: remove expiration from a key
PERSIST session:abc123          # key now lives forever

# TYPE: check the data type of a key
TYPE user:1:name                # "string"

# KEYS: find keys matching a pattern (AVOID in production)
KEYS user:*                     # all keys starting with "user:"

# SCAN: iterate keys safely without blocking (production-safe)
SCAN 0 MATCH user:* COUNT 100  # returns cursor + batch of matching keys
# Keep calling SCAN with returned cursor until cursor is 0

Important: Never use KEYS in production. It scans the entire keyspace and blocks the server. Use SCAN instead, which iterates incrementally without blocking.

5. String Operations

# Basic set and get
SET counter 100
GET counter                     # "100"

# Atomic increment and decrement
INCR counter                    # 101 (atomic, safe for concurrent access)
DECR counter                    # 100
INCRBY counter 50               # 150
DECRBY counter 25               # 125
INCRBYFLOAT price 9.99          # works with floating point

# Append to a string
SET greeting "Hello"
APPEND greeting " World"        # "Hello World"
STRLEN greeting                 # 11

# Set and get multiple keys at once
MSET user:1:name "Alice" user:1:email "alice@example.com" user:1:role "admin"
MGET user:1:name user:1:email user:1:role
# Returns: ["Alice", "alice@example.com", "admin"]

# Conditional set
SET lock:resource1 "owner1" NX  # NX = only set if key does NOT exist
SET lock:resource1 "owner2" NX  # fails because key already exists
SET config:debug "true" XX      # XX = only set if key DOES exist

# SET with GET option (Redis 6.2+)
SET counter 200 GET             # returns old value, sets to 200

String operations like INCR are atomic — even if multiple clients call INCR on the same key simultaneously, Redis guarantees no race conditions. This makes strings ideal for counters, rate limiters, and distributed locks.

6. List Operations

# Push elements to the left (head) or right (tail)
LPUSH tasks "send email"        # push to head
LPUSH tasks "process payment"   # push to head
RPUSH tasks "generate report"   # push to tail
# List: ["process payment", "send email", "generate report"]

# Pop elements from either end
LPOP tasks                      # "process payment" (from head)
RPOP tasks                      # "generate report" (from tail)

# Get a range of elements (0-indexed, inclusive)
RPUSH colors "red" "green" "blue" "yellow" "purple"
LRANGE colors 0 -1              # all elements
LRANGE colors 0 2               # first 3: ["red", "green", "blue"]
LRANGE colors -2 -1             # last 2: ["yellow", "purple"]

# Get list length
LLEN colors                     # 5

# Get element by index
LINDEX colors 0                 # "red"
LINDEX colors -1                # "purple"

# Set element by index
LSET colors 1 "lime"           # replace index 1 with "lime"

# Remove elements by value
LREM colors 0 "blue"           # remove all occurrences of "blue"

# Trim list to a range (useful for capping lists)
LTRIM recent_searches 0 99     # keep only last 100 items

# Blocking pop (for job queues)
BLPOP queue:jobs 30            # wait up to 30s for an element
BRPOP queue:jobs 0             # wait indefinitely

# Move element between lists atomically
LMOVE source dest LEFT RIGHT   # pop from source left, push to dest right

Lists are excellent for job queues: producers RPUSH tasks, and workers BLPOP to wait for and consume them. The blocking variant means workers sleep efficiently instead of polling.

7. Set Operations

# Add members to a set
SADD tags:post:1 "redis" "database" "nosql" "caching"
SADD tags:post:2 "redis" "python" "caching" "tutorial"

# Get all members
SMEMBERS tags:post:1            # {"redis", "database", "nosql", "caching"}

# Check membership
SISMEMBER tags:post:1 "redis"   # 1 (true)
SISMEMBER tags:post:1 "java"    # 0 (false)

# Count members
SCARD tags:post:1               # 4

# Remove members
SREM tags:post:1 "nosql"        # removes "nosql"

# Set operations: intersection, union, difference
SINTER tags:post:1 tags:post:2
# {"redis", "caching"} -- tags common to both posts

SUNION tags:post:1 tags:post:2
# all unique tags from both posts

SDIFF tags:post:1 tags:post:2
# {"database", "nosql"} -- in post:1 but not in post:2

# Store results of set operations in a new key
SINTERSTORE common_tags tags:post:1 tags:post:2
SUNIONSTORE all_tags tags:post:1 tags:post:2

# Random member
SRANDMEMBER tags:post:1         # random element without removing
SPOP tags:post:1                # random element, removes it

Sets are perfect for tracking unique items: unique visitors, user permissions, tags, and online users. The set operations let you find common interests between users or compute tag intersections for content recommendations.

8. Hash Operations

# Set fields in a hash (like an object or row)
HSET user:100 name "Alice" email "alice@example.com" role "admin" login_count 0

# Get a single field
HGET user:100 name              # "Alice"

# Get multiple fields
HMGET user:100 name email       # ["Alice", "alice@example.com"]

# Get all fields and values
HGETALL user:100
# {"name":"Alice", "email":"alice@example.com", "role":"admin", "login_count":"0"}

# Check if a field exists
HEXISTS user:100 email          # 1

# Delete a field
HDEL user:100 role              # removes the "role" field

# Get all field names or all values
HKEYS user:100                  # ["name", "email", "login_count"]
HVALS user:100                  # ["Alice", "alice@example.com", "0"]

# Count fields
HLEN user:100                   # 3

# Increment a numeric field
HINCRBY user:100 login_count 1  # atomically increment
HINCRBYFLOAT product:1 price 0.50

# Set field only if it does not exist
HSETNX user:100 created_at "2026-02-12"

Hashes are memory-efficient for storing objects. Instead of serializing a user into a JSON string, store each field separately in a hash. This lets you read or update individual fields without loading the entire object.

9. Sorted Set Operations

# Add members with scores
ZADD leaderboard 1500 "alice" 1200 "bob" 1800 "charlie" 900 "dave"

# Get members by rank (lowest score first, 0-indexed)
ZRANGE leaderboard 0 -1                # all, ascending by score
ZRANGE leaderboard 0 -1 WITHSCORES     # include scores

# Get members by rank (highest score first)
ZREVRANGE leaderboard 0 2              # top 3 players
# ["charlie", "alice", "bob"]

# Get members within a score range
ZRANGEBYSCORE leaderboard 1000 1600    # scores between 1000-1600
ZRANGEBYSCORE leaderboard -inf +inf    # all members by score

# Get rank of a member (0-indexed)
ZRANK leaderboard "alice"              # rank from lowest score
ZREVRANK leaderboard "alice"           # rank from highest score

# Get score of a member
ZSCORE leaderboard "alice"             # "1500"

# Increment a member's score
ZINCRBY leaderboard 300 "bob"          # bob is now 1500

# Count members in a score range
ZCOUNT leaderboard 1000 1600

# Remove members
ZREM leaderboard "dave"
ZREMRANGEBYSCORE leaderboard 0 999     # remove all with score < 1000
ZREMRANGEBYRANK leaderboard 0 1        # remove bottom 2

# Total members
ZCARD leaderboard

Sorted sets are the go-to structure for leaderboards, priority queues, and time-based indexes. Use timestamps as scores to create a time-ordered index that supports efficient range queries.

10. Pub/Sub Messaging

Redis Pub/Sub lets you broadcast messages to multiple subscribers in real time. Publishers send messages to channels; subscribers receive messages from channels they are listening to.

# Terminal 1: Subscribe to a channel
SUBSCRIBE notifications
# Waiting for messages...

# Terminal 2: Publish a message
PUBLISH notifications "New order #1234 received"
# Terminal 1 receives: "New order #1234 received"

# Subscribe to multiple channels
SUBSCRIBE notifications alerts system

# Pattern-based subscription (wildcard matching)
PSUBSCRIBE user:*
# Receives messages from user:login, user:logout, user:signup, etc.

# Publish to specific channels
PUBLISH user:login '{"user":"alice","ip":"192.168.1.1"}'
PUBLISH user:signup '{"user":"bob","email":"bob@example.com"}'

# Check how many subscribers a channel has
PUBSUB NUMSUB notifications

Pub/Sub limitations: messages are fire-and-forget. If a subscriber is disconnected when a message is published, it misses that message permanently. For reliable messaging with acknowledgments and replay, use Redis Streams instead.

11. Transactions (MULTI/EXEC)

Redis transactions group multiple commands into a single atomic operation. All commands execute sequentially without interruption from other clients.

# Basic transaction: transfer points between users
MULTI                           # start transaction
DECRBY user:alice:points 100    # queued
INCRBY user:bob:points 100      # queued
EXEC                            # execute all commands atomically

# DISCARD: cancel a transaction
MULTI
SET key1 "value1"
SET key2 "value2"
DISCARD                         # cancel, nothing is executed

# WATCH: optimistic locking (check-and-set)
WATCH user:alice:balance        # watch for changes
# read current value
GET user:alice:balance
# If another client modifies the key before EXEC, transaction aborts
MULTI
DECRBY user:alice:balance 100
INCRBY user:bob:balance 100
EXEC                            # returns nil if watched key changed

WATCH enables optimistic locking: if any watched key is modified by another client between WATCH and EXEC, the transaction aborts and returns nil. Your application retries the entire read-modify-write cycle.

12. Persistence: RDB vs AOF

Redis stores data in memory, but it needs persistence to survive restarts. Redis offers two mechanisms that can be used independently or together.

RDB (Redis Database) Snapshots

# redis.conf: save a snapshot at specified intervals
save 3600 1        # after 3600 sec if at least 1 key changed
save 300 100       # after 300 sec if at least 100 keys changed
save 60 10000      # after 60 sec if at least 10000 keys changed

dbfilename dump.rdb
dir /var/lib/redis/

# Manual snapshot
BGSAVE             # fork a child process to write dump.rdb
SAVE               # block until snapshot is complete (avoid in production)

RDB pros: compact single-file backup, fast restarts, minimal performance impact. RDB cons: you lose data written between snapshots (up to minutes of data).

AOF (Append Only File)

# redis.conf: enable AOF
appendonly yes
appendfilename "appendonly.aof"

# fsync policy (trade-off between safety and performance)
# appendfsync always     # fsync on every write (safest, slowest)
appendfsync everysec     # fsync every second (good default)
# appendfsync no         # let the OS decide (fastest, least safe)

# AOF rewrite: compact the file
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
BGREWRITEAOF             # manual rewrite

AOF pros: minimal data loss (at most 1 second with everysec), human-readable log. AOF cons: larger files, slower restarts than RDB.

Recommended Production Configuration

# Enable both for maximum safety
save 3600 1
save 300 100
save 60 10000
appendonly yes
appendfsync everysec

# Redis uses AOF to restore data (more complete)
# RDB provides fast backups for disaster recovery

13. Redis with Python

# Install: pip install redis
import redis
import json

# Connection with pool (reuse across your app)
pool = redis.ConnectionPool(host='localhost', port=6379, db=0,
                            max_connections=20, decode_responses=True)
r = redis.Redis(connection_pool=pool)

# String operations
r.set('user:name', 'Alice')
r.set('session:token', 'abc123', ex=3600)  # expires in 1 hour
name = r.get('user:name')  # 'Alice'

# Hash operations
r.hset('user:100', mapping={
    'name': 'Alice', 'email': 'alice@example.com', 'login_count': 0
})
user = r.hgetall('user:100')
r.hincrby('user:100', 'login_count', 1)

# List as a job queue
r.rpush('queue:emails', 'welcome_alice', 'reset_bob', 'verify_charlie')
job = r.lpop('queue:emails')  # 'welcome_alice'

# Sorted set leaderboard
r.zadd('leaderboard', {'alice': 1500, 'bob': 1200, 'charlie': 1800})
top_players = r.zrevrange('leaderboard', 0, 9, withscores=True)

# Pipeline: batch multiple commands (reduces round trips)
pipe = r.pipeline()
pipe.incr('page:views:home')
pipe.incr('page:views:about')
pipe.expire('page:views:home', 86400)
pipe.expire('page:views:about', 86400)
results = pipe.execute()  # all commands sent in one round trip

# Pub/Sub
pubsub = r.pubsub()
pubsub.subscribe('notifications')
for message in pubsub.listen():
    if message['type'] == 'message':
        data = json.loads(message['data'])
        print(f"Received: {data}")

14. Redis with Node.js

// Install: npm install ioredis
const Redis = require('ioredis');
const redis = new Redis({
  host: '127.0.0.1', port: 6379, password: 'yourpassword',
  retryStrategy: (times) => Math.min(times * 50, 2000)
});

// String operations
await redis.set('user:name', 'Alice');
await redis.set('session:token', 'abc123', 'EX', 3600);
const name = await redis.get('user:name'); // 'Alice'

// Hash operations
await redis.hset('user:100', { name: 'Alice', email: 'alice@example.com' });
const user = await redis.hgetall('user:100');
await redis.hincrby('user:100', 'loginCount', 1);

// Pipeline: batch commands
const pipeline = redis.pipeline();
pipeline.incr('page:views:home');
pipeline.incr('page:views:about');
pipeline.expire('page:views:home', 86400);
const results = await pipeline.exec();

// Pub/Sub (requires separate connection)
const sub = new Redis();
sub.subscribe('notifications', (err, count) => {
  console.log(`Subscribed to ${count} channels`);
});
sub.on('message', (channel, message) => {
  console.log(`${channel}: ${message}`);
});
await redis.publish('notifications', 'New order received');

// Cluster connection
const cluster = new Redis.Cluster([
  { host: '192.168.1.101', port: 6379 },
  { host: '192.168.1.102', port: 6379 }
]);

// Graceful shutdown
process.on('SIGTERM', async () => {
  await redis.quit();
  process.exit(0);
});

15. Caching Strategies and Patterns

Cache-Aside (Lazy Loading)

The most common pattern: the application checks Redis first. On a miss, it loads from the database and writes to Redis.

async function getUser(userId) {
  const cached = await redis.get(`user:${userId}`);
  if (cached) return JSON.parse(cached);

  const user = await db.query('SELECT * FROM users WHERE id = ?', [userId]);
  await redis.set(`user:${userId}`, JSON.stringify(user), 'EX', 3600);
  return user;
}

Write-Through

Every write goes to both Redis and the database. Keeps cache consistent but adds write latency.

async function updateUser(userId, data) {
  await db.query('UPDATE users SET ? WHERE id = ?', [data, userId]);
  await redis.set(`user:${userId}`, JSON.stringify(data), 'EX', 3600);
}

Cache Invalidation Patterns

# Time-based: set TTL on every cached key
SET user:100 '{"name":"Alice"}' EX 3600

# Event-based: delete cache when data changes
# After updating user in database:
DEL user:100

# Pattern-based: use SCAN + DEL (never KEYS in production)
# Scan for matching keys, then delete them in batches

Cache Stampede Prevention

# Problem: popular key expires, hundreds of requests hit the database.
# Solution: use a lock so only one request rebuilds the cache.
async function getWithLock(key, ttl, fetchFn) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const lockKey = `lock:${key}`;
  const acquired = await redis.set(lockKey, '1', 'NX', 'EX', 10);
  if (acquired) {
    const data = await fetchFn();
    await redis.set(key, JSON.stringify(data), 'EX', ttl);
    await redis.del(lockKey);
    return data;
  }
  // Another process is rebuilding; wait and retry
  await sleep(100);
  return getWithLock(key, ttl, fetchFn);
}

16. Performance Tuning and Best Practices

• Use pipelining — batch multiple commands into one round trip. A pipeline of 100 commands is dramatically faster than 100 individual commands.
• Set maxmemory and eviction policy — always configure maxmemory to prevent Redis from consuming all RAM. Use allkeys-lru for caching.
• Use appropriate data structures — a hash with 10 fields is more memory-efficient than 10 separate string keys.
• Avoid large keys — keep values under 100 KB. Break large objects into smaller, logically grouped keys.
• Use SCAN instead of KEYS — KEYS blocks the server while scanning. SCAN iterates incrementally.
• Set TTL on everything — cache keys without TTL accumulate forever. Always set an expiration.
• Use connection pooling — creating a new TCP connection per operation is expensive. Reuse connections.
• Use UNLINK instead of DEL for large keys — UNLINK frees memory asynchronously in the background.

# Check memory usage
redis-cli INFO memory | grep used_memory_human

# Check cache hit ratio
redis-cli INFO stats | grep keyspace
# keyspace_hits:150000
# keyspace_misses:5000
# Hit ratio: 150000 / (150000 + 5000) = 96.8%

# Recommended redis.conf for production
maxmemory 2gb
maxmemory-policy allkeys-lru
tcp-backlog 511
timeout 300
tcp-keepalive 300

# Monitor for slow commands
CONFIG SET slowlog-log-slower-than 10000  # log commands slower than 10ms
SLOWLOG GET 10                            # view the 10 slowest commands

17. Redis Cluster and Sentinel

Redis Sentinel (High Availability)

Sentinel monitors Redis instances and performs automatic failover. When the primary goes down, Sentinel promotes a replica to primary and reconfigures other replicas.

# sentinel.conf
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

# Start sentinel
redis-sentinel /path/to/sentinel.conf

# Connect through Sentinel (Python)
from redis.sentinel import Sentinel
sentinel = Sentinel([('sentinel1', 26379), ('sentinel2', 26379)])
master = sentinel.master_for('mymaster', decode_responses=True)
replica = sentinel.slave_for('mymaster', decode_responses=True)

master.set('key', 'value')       # writes go to primary
value = replica.get('key')       # reads from replica

Redis Cluster (Horizontal Scaling)

Redis Cluster partitions data across multiple nodes using 16384 hash slots. Each primary node owns a subset of slots and can have replicas for failover.

# Create a 6-node cluster (3 primaries + 3 replicas)
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

# Connect to cluster (Python)
from redis.cluster import RedisCluster
rc = RedisCluster(host='192.168.1.101', port=6379, decode_responses=True)
rc.set('key', 'value')  # automatically routed to correct node

# Connect to cluster (Node.js with ioredis)
const cluster = new Redis.Cluster([
  { host: '192.168.1.101', port: 6379 },
  { host: '192.168.1.102', port: 6379 }
]);

# Hash tags: force related keys to the same slot
SET {user:100}.profile '{"name":"Alice"}'
SET {user:100}.session '{"token":"abc"}'
# Both keys land on the same node, enabling MULTI on them

When to use Sentinel vs Cluster: use Sentinel when your dataset fits on a single server and you only need failover. Use Cluster when you need more memory than one server provides or need to distribute write load across multiple primaries.

Frequently Asked Questions

Conclusion

Redis transforms application performance by moving frequently accessed data into memory. Start with the basics — use it as a cache alongside your primary database with cache-aside pattern and sensible TTLs. As your needs grow, leverage its rich data structures: sorted sets for leaderboards, lists for queues, pub/sub for real-time messaging, and hashes for structured records.

For production deployments, always configure persistence (both RDB and AOF), set memory limits with an appropriate eviction policy, use connection pooling in your application, and set up Sentinel or Cluster for high availability.

Learn More

• Docker Compose: The Complete Guide — deploy Redis and your application stack with a single YAML file
• Docker Networking Complete Guide — understand how Redis containers communicate in Docker networks
• Python Data Structures Guide — Python data structures to complement your Redis integration
• JSON Formatter — format and validate JSON data from Redis responses