Redis Quick Reference

Analogy categoryAnalogies

Redis Command Cheat Sheet Overview

Redis commands are organized around data types — Strings, Hashes, Lists, Sets, and Sorted Sets are the core five — plus separate command families for key management (expiry, deletion, renaming) and server administration (INFO, CONFIG, persistence). Nearly every command follows a consistent pattern of TYPE-PREFIXED-VERB KEY [ARGS], such as HSET, LPUSH, or ZADD, which makes the command set easier to memorize once you recognize the type prefixes (H for Hash, L for List, S for Set, Z for Sorted Set).

🏏

Cricket analogy: Like a scorecard organized into clear sections for batting, bowling, and fielding stats, Redis organizes commands by type prefix (H, L, S, Z) so related operations are easy to group and recall.

Strings, Hashes, Lists, Sets, and Sorted Sets

Strings support SET/GET/INCR/APPEND and are the simplest type, often used for counters and cached blobs. Hashes (HSET/HGET/HGETALL/HDEL) model an object's fields under one key. Lists (LPUSH/RPUSH/LPOP/RPOP/LRANGE) are ordered sequences good for queues and recent-activity lists. Sets (SADD/SREM/SISMEMBER/SINTER) hold unique unordered members and support set algebra like intersection and union. Sorted Sets (ZADD/ZRANGE/ZRANK/ZINCRBY) attach a score to each member and keep it ordered, ideal for leaderboards and priority queues.

🏏

Cricket analogy: Like a single scoreboard number for total runs (a String counter via INCR), a player's full stat card as fields under one name (a Hash), the over-by-over ball sequence (a List), the unique set of players who've played a Test (a Set), and the ranked run-scorer table (a Sorted Set) each map to a different Redis type.

bash

# Strings
SET counter 1
INCR counter
GET counter

# Hashes
HSET user:1001 name "Asha" plan "pro"
HGETALL user:1001

# Lists
LPUSH recent_logins "user:1001"
LRANGE recent_logins 0 9

# Sets
SADD tags:post:55 "redis" "databases"
SISMEMBER tags:post:55 "redis"

# Sorted Sets
ZADD leaderboard 250 "user:1001"
ZREVRANGE leaderboard 0 4 WITHSCORES

Key Management and Expiry

EXPIRE key seconds (or PEXPIRE for milliseconds) sets a time-to-live on any key, TTL key returns remaining seconds (-1 means no expiry, -2 means the key doesn't exist), and PERSIST removes an expiry. EXISTS, DEL, and RENAME handle basic key lifecycle, while SCAN key* (never KEYS key* in production, since KEYS blocks the single-threaded server while scanning the entire keyspace) safely iterates keys matching a pattern in small cursor-based batches.

🏏

Cricket analogy: Like a rain-delay countdown clock on the big screen (TTL) ticking down until the umpires call play, EXPIRE sets that countdown on a key, and PERSIST is like canceling the delay so the match resumes without a deadline.

bash

SET session:abc123 "user:1001" EX 3600
TTL session:abc123          # seconds remaining, or -1/-2
PERSIST session:abc123      # removes the expiry
EXISTS session:abc123
DEL session:abc123

# Safe iteration instead of KEYS
SCAN 0 MATCH "session:*" COUNT 100

Server and Admin Commands

INFO returns server stats grouped into sections (memory, replication, persistence, clients); CONFIG GET/SET reads or changes runtime configuration like maxmemory-policy without a restart; DBSIZE returns the key count for the current logical database; and BGSAVE/BGREWRITEAOF trigger a background RDB snapshot or AOF compaction without blocking client traffic, since the actual work happens in a forked child process.

🏏

Cricket analogy: Like a broadcaster's on-screen stats panel breaking down run rate, partnerships, and bowling figures into distinct sections, INFO returns Redis server stats grouped into sections like memory, replication, and persistence.

BGSAVE and BGREWRITEAOF fork a child process to do the heavy work, so the parent Redis process keeps serving commands — but forking a large dataset can briefly spike memory usage (copy-on-write) and CPU, so schedule them for low-traffic windows on memory-constrained instances.

Command prefixes (H, L, S, Z) signal which data type a command operates on: Hash, List, Set, Sorted Set.
Strings support INCR/APPEND for counters and simple values; Hashes group an object's fields under one key.
Use EXPIRE/TTL/PERSIST to manage key lifecycles instead of manually tracking expiry in application code.
Never run KEYS pattern* in production; use SCAN for safe, non-blocking cursor-based iteration.
INFO and CONFIG GET/SET are the go-to commands for inspecting and tuning a running server.
DBSIZE gives a quick key count; BGSAVE/BGREWRITEAOF handle persistence maintenance without blocking clients.
Sorted Sets (ZADD/ZRANGE/ZRANK) are the standard structure for leaderboards and any ranked, scored data.