Redis Cheatsheet - Complete Reference 2025

This cheatsheet provides a comprehensive reference for Redis, covering essential commands, data structures, common usage patterns, and best practices for developers. All information is current as of December 30, 2025, reflecting features and recommendations for Redis 7.4.

Quick Reference: Most Used Commands

I. Basic Data Types & Operations

Redis is a data structure server, supporting various data types.

1. Strings

Binary-safe strings, up to 512MB.

2. Hashes

Maps string fields to string values, ideal for representing objects.

3. Lists

Ordered collections of strings, implemented as linked lists. Good for queues, recent items.

4. Sets

Unordered collections of unique strings. Good for tags, unique visitors.

5. Sorted Sets

Collections of unique strings where each member is associated with a score. Members are ordered by score. Good for leaderboards, timed events.

II. Key Management & Expiration

Managing keys and their lifecycles is crucial for efficient Redis usage.

1. Key Commands

2. Pattern Matching with SCAN

// Syntax for SCAN
SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]

Explanation: SCAN is an iterator that allows you to incrementally iterate over the keyspace. It returns a new cursor to use in the next call, along with a subset of keys matching the MATCH pattern (if provided) and optionally filtered by TYPE. Use Case: Safely iterate over large numbers of keys in production without blocking the server, unlike KEYS.

# Initial call
SCAN 0 MATCH user:* COUNT 100

# Example output:
# 1) "128"  (the new cursor)
# 2) 1) "user:101"
#    2) "user:205"
#    ... (up to 100 keys)

# Next call using the cursor from the previous result
SCAN 128 MATCH user:* COUNT 100

III. Transactions & Scripting

Ensure atomicity and complex operations.

1. Transactions (MULTI/EXEC)

Redis transactions allow a group of commands to be executed as a single, atomic operation.

// Syntax for Transactions
MULTI
COMMAND1
COMMAND2
...
EXEC

Explanation:

• MULTI: Starts a transaction. All subsequent commands are queued.
• EXEC: Executes all queued commands atomically.
• DISCARD: Flushes all queued commands and exits the transaction.
• WATCH key [key ...]: Monitors keys for changes. If any watched key is modified before EXEC, the transaction is aborted. Use Case: Transferring funds, updating multiple related counters atomically.

# Example: Atomic decrement and check
WATCH user:1:balance
GET user:1:balance
# In your application, check if balance is sufficient
# If yes:
MULTI
DECRBY user:1:balance 100
RPUSH transaction:log "User 1 paid 100"
EXEC
# If no, or WATCH detected a change, EXEC will return nil,
# and you can retry or inform the user.

2. Lua Scripting (EVAL)

Execute custom server-side scripts for complex, atomic operations.

// Syntax for EVAL
EVAL script numkeys key [key ...] arg [arg ...]

Explanation: EVAL executes a Lua script. numkeys specifies how many of the subsequent arguments are key names (accessed via KEYS table in Lua), and the rest are arguments (accessed via ARGV table). Use Case: Implementing custom atomic commands, complex rate limiters, or fetching multiple related items with conditional logic.

-- Lua script for an atomic rate limiter
-- KEYS[1]: rate limit key (e.g., "rate_limit:user:123")
-- ARGV[1]: max requests allowed
-- ARGV[2]: time window in seconds
-- ARGV[3]: current timestamp
local key = KEYS[1]
local max_requests = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current_time = tonumber(ARGV[3])

redis.call('ZREMRANGEBYSCORE', key, '-inf', current_time - window)
local current_requests = redis.call('ZCARD', key)

if current_requests < max_requests then
    redis.call('ZADD', key, current_time, current_time .. math.random()) -- Add with unique member
    redis.call('EXPIRE', key, window + 1) -- Set expiration slightly longer than window
    return 1 -- Request allowed
else
    return 0 -- Request denied
end

# Example usage of the rate limiter script (assuming script is loaded or passed directly)
# KEYS[1] = "rate_limit:user:123"
# ARGV[1] = 10 (max requests)
# ARGV[2] = 60 (window in seconds)
# ARGV[3] = <current_unix_timestamp>
EVAL "local key = KEYS[1] ... return 0 end" 1 rate_limit:user:123 10 60 1735689600

EVALSHA: For production, load scripts once with SCRIPT LOAD to get an SHA1 digest, then execute with EVALSHA to save bandwidth.

IV. Pub/Sub & Streams

Real-time messaging and event streaming.

1. Publish/Subscribe (Pub/Sub)

Simple messaging system where senders (publishers) send messages to channels, and receivers (subscribers) listen to channels.

2. Streams (Redis 5.0+)

A more robust and persistent message queue, log, and event store.

V. Server Management & Persistence

Monitoring, configuration, and data durability.

1. Server Information & Configuration

2. Persistence

Redis offers two main persistence options: RDB (snapshotting) and AOF (append-only file).

• RDB (Redis Database Backup): Point-in-time snapshots of your dataset.
  • SAVE: Synchronously saves the dataset to disk. Blocks the server.
  • BGSAVE: Asynchronously saves the dataset to disk in the background. Non-blocking.
• AOF (Append-Only File): Logs every write operation received by the server.
  • BGREWRITEAOF: Rewrites the AOF file in the background to minimize its size.

# Manually trigger a background save
BGSAVE

# Manually trigger AOF rewrite
BGREWRITEAOF

3. Security (ACL)

Redis 6.0+ introduced Access Control Lists (ACLs) for fine-grained permissions.

// Syntax for ACL
ACL SETUSER username [password] [rules ...]

Explanation: ACLs allow you to define users with specific permissions for commands, keys, and Pub/Sub channels. Use Case: Restricting certain applications or microservices to only access specific keys or commands.

# Create a user 'app_cache' with password 'cache_pass'
# Can only use GET/SET/DEL commands
# Can only access keys starting with 'cache:'
ACL SETUSER app_cache on >cache_pass +@read +@write ~cache:*

VI. Common Patterns

Practical use cases and best practices.

1. Caching

// Basic Caching
SET user:profile:123 '{"name":"Alice", "email":"alice@example.com"}' EX 3600
GET user:profile:123

// Cache Invalidation (explicit)
DEL user:profile:123

// Cache Invalidation (on update)
// When user profile is updated in DB, also update/delete in Redis
SET user:profile:123 '{"name":"Alice Updated", "email":"alice_new@example.com"}' EX 3600

Best Practice: Use EX or PX for expiration. Implement a cache-aside pattern.

2. Rate Limiting

-- Lua script for a sliding window rate limiter (as shown above)
-- KEYS[1]: rate limit key
-- ARGV[1]: max requests
-- ARGV[2]: time window (seconds)
-- ARGV[3]: current timestamp (milliseconds for better precision)
local key = KEYS[1]
local max_requests = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current_time = tonumber(ARGV[3])

-- Remove old requests
redis.call('ZREMRANGEBYSCORE', key, '-inf', current_time - (window * 1000))

-- Count current requests
local current_requests = redis.call('ZCARD', key)

if current_requests < max_requests then
    -- Add current request
    redis.call('ZADD', key, current_time, current_time .. '-' .. math.random(0, 100000))
    -- Set expiration for the key to ensure it's cleaned up
    redis.call('PEXPIRE', key, window * 1000 + 1000) -- +1 second buffer
    return 1 -- Allowed
else
    return 0 -- Denied
end

# Example: Allow 10 requests per 60 seconds for user:123
# Assuming current_ms is current Unix timestamp in milliseconds
EVALSHA <sha1_of_script> 1 rate_limit:user:123 10 60 <current_ms>

Best Practice: Use Lua scripts for atomic rate limiting logic.

3. Distributed Locks

// Acquire Lock
SET resource:lock:<id> <owner_id> NX PX <milliseconds>
// Returns OK if acquired, nil if not.

// Release Lock (requires checking owner_id for safety, ideally with Lua)
// Lua script for safe release:
-- KEYS[1]: lock key
-- ARGV[1]: expected owner_id
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

Best Practice: Use SET key value NX PX milliseconds for acquiring. Releasing should be done atomically (e.g., with Lua) to prevent one client from releasing another’s lock. Implement retry logic with exponential backoff.

4. Message Queues (Simple)

// Producer
LPUSH tasks "task_id_1" "task_id_2"

// Consumer (blocking)
BRPOP tasks 0 // Blocks indefinitely until a task is available

Best Practice: For simple task queues, LPUSH/BRPOP works well. For more robust, persistent, and consumer-group-aware queues, use Redis Streams.

5. Leaderboards/Ranking

// Add/Update player scores
ZADD game:leaderboard 1000 "player:Alice" 1200 "player:Bob" 950 "player:Charlie"

// Get top 10 players
ZREVRANGE game:leaderboard 0 9 WITHSCORES

// Get player's rank (0-indexed, ascending)
ZRANK game:leaderboard "player:Alice"

// Get player's score
ZSCORE game:leaderboard "player:Alice"

Best Practice: Sorted Sets are purpose-built for leaderboards.

6. Session Management

// Store user session data
HSET session:user:123 id 123 username "Alice" login_time <timestamp>
EXPIRE session:user:123 1800 // Session expires in 30 minutes

// Retrieve session data
HGETALL session:user:123

// Check if session exists
EXISTS session:user:123

Best Practice: Use Hashes for structured session data and EXPIRE for automatic cleanup.

VII. Tips & Tricks

1. KEYS vs SCAN

• KEYS: Use only in development or on very small, non-production datasets. It’s a blocking command and can severely impact performance on large databases.
• SCAN: Always use SCAN in production for iterating over keys. It’s non-blocking and provides a cursor for incremental iteration.

2. Memory Usage

• Use INFO memory to get an overview of memory consumption.
• Use MEMORY USAGE key to estimate the memory used by a specific key.
• Consider using Redis data structures efficiently (e.g., small hashes/lists can be optimized for memory).
• Set maxmemory and a maxmemory-policy in redis.conf to prevent Redis from running out of memory.

3. Atomic Operations

• Redis commands are atomic by default.
• For multi-command atomicity, use MULTI/EXEC transactions or Lua scripting. Lua scripts are generally preferred for complex logic as they are executed entirely on the server.

4. Connection Pooling

• Always use connection pooling in your application to manage connections efficiently and avoid overhead of establishing new connections for every command.

5. Pipelining

• Send multiple commands to Redis in a single round trip to reduce network latency, especially for bulk operations. Most Redis client libraries support pipelining.

6. Data Modeling

• Think about your access patterns. Redis is very flexible, but modeling data to fit its strengths (e.g., using hashes for objects, sorted sets for rankings) leads to better performance.
• Use appropriate key naming conventions (e.g., object_type:id:field).

7. Troubleshooting

• NOAUTH Authentication required: This error means your Redis server is configured with a password, but your client isn’t providing it. Check redis.conf for requirepass. Use the AUTH password command.
• Connection issues: Check Redis server status (redis-cli PING), firewall rules, and ensure the client is connecting to the correct host and port.
• High CPU/Memory usage: Use INFO commands to diagnose. INFO CPU shows CPU usage, INFO memory shows memory. MONITOR can reveal high-frequency commands. redis-cli --latency can help detect performance issues.
• Data loss: Ensure persistence (RDB/AOF) is configured correctly for your durability requirements.

VIII. Version Information

This cheatsheet is based on Redis 7.4, which is anticipated to be the latest stable major version by December 30, 2025, building upon the features of Redis 7.2 (released mid-2023).

• Key Features (Redis 7.x series):
  • ACLv2: Enhanced Access Control Lists for more granular permissions.
  • Functions: Server-side functions written in Lua, offering a more structured way to extend Redis logic than raw EVAL scripts.
  • Sharded Pub/Sub: Improves scalability for Pub/Sub by allowing messages to be sharded across multiple nodes in a cluster.
  • Client-side Caching (Tracking): Optimizations for client-side caching to reduce network round-trips.
  • Command improvements: Various new arguments and options for existing commands, and new commands for specific use cases.
  • Performance enhancements: Continuous improvements in core performance and memory efficiency.

Redis maintains strong backward compatibility, so commands from older versions (e.g., 6.x) generally work as expected, but leveraging newer features like ACLs and Functions requires compatible server and client versions.

IX. References

1. Official Redis Documentation
2. Redis Commands Reference
3. Redis University
4. Stack Overflow - Redis Tag

Transparency Note

This cheatsheet was generated by an AI expert based on a comprehensive understanding of Redis, its official documentation, common usage patterns, and best practices. Information is current as of December 30, 2025, with reasonable projections for Redis versioning and feature sets. While every effort has been made to ensure accuracy and practicality, always refer to the official Redis documentation for the most definitive and up-to-date information.