Back to All Cheatsheet Libraries cheatsheets

Redis

redis-cli command reference by data type, persistence and scaling concepts, and a correct-caching workflow.

Total Commands: 0
Category Command Description
StringsSET key valueSets a string key to a value, creating or overwriting it.
StringsGET keyReads the value of a string key.
StringsSET key value EX 60Sets a key with a 60-second expiry — the core primitive behind Redis-based caching.
ExpiryEXPIRE key 60Sets a TTL on an existing key.
ExpiryTTL keyReturns seconds remaining until expiry, or -1 if no TTL is set.
ListsLPUSH mylist valuePushes a value onto the left end of a list — common for building a queue.
ListsRPOP mylistPops a value from the right end — LPUSH+RPOP together implement a FIFO queue.
HashesHSET user:1 name "Alex" age 30Sets multiple fields on a hash — good fit for a small object like a user record.
HashesHGETALL user:1Returns every field/value pair in a hash.
SetsSADD tags:post1 "redis" "cache"Adds members to a set — duplicates are silently ignored.
Sorted SetsZADD leaderboard 100 "player1"Adds a member with a score — sorted sets are how Redis implements leaderboards/rankings.
Pub/SubPUBLISH channel "message"Publishes a message to a channel — subscribers connected via SUBSCRIBE receive it immediately.
IntrospectionKEYS pattern*Finds keys matching a pattern — blocks the server on a large dataset; use SCAN in production instead.
ServerINFODumps server stats — memory usage, connected clients, keyspace hits/misses.

Core Data Types

String

Binary-safe text or a number — the simplest type, also used for counters via INCR/DECR.

List

An ordered collection of strings, efficient at both ends — the basis for simple queues.

Hash

A map of field-value pairs under one key — a compact way to store an object without a separate key per field.

Set

An unordered collection of unique strings — fast membership checks and set operations (union, intersect).

Sorted Set

A set where every member has a score, kept in score order — powers leaderboards and range queries by score.

Stream

An append-only log of entries with IDs — used for event/message processing, similar in spirit to a lightweight Kafka topic.

Persistence & Scaling

RDB Snapshots

Point-in-time dump

AOF

Append-only logMore durable

Replication

Primary/replica

Cluster Mode

Sharded across nodes

Using Redis as a Cache Correctly

The most common Redis use case, and the details that keep it from causing subtle bugs.

1

Always set a TTL

A cache key with no expiry is a slow memory leak — SET with EX (or SETEX) so stale data ages out even if invalidation logic is imperfect.

2

Namespace keys with colons

user:1:profile, session:abc123 — keeps related keys groupable and makes SCAN patterns meaningful.

3

Handle cache misses gracefully in the app

Redis being down or a key missing should degrade to hitting the source of truth, not error out — a cache is an optimization, not a dependency.

4

Watch eviction policy under memory pressure

maxmemory-policy (e.g. allkeys-lru) determines what gets dropped when Redis hits its memory limit — the default (noeviction) just starts rejecting writes instead.

Quick Tips

Avoid KEYS in production
KEYS scans the entire keyspace and blocks the single-threaded server while it runs — use SCAN, which iterates incrementally without blocking.
Redis is in-memory by default
Without RDB/AOF persistence enabled, a restart loses everything — fine for a pure cache, not fine for anything treated as a source of truth.
Bind to localhost or require a password
An open, unauthenticated Redis instance on the public internet is a well-known, actively scanned-for misconfiguration — never leave the default port exposed without auth.