Redis guide

What Redis does in production

Redis stores data in memory for sub-millisecond reads and writes. It is not a full relational database — use it where speed matters and some data loss on crash may be acceptable (with persistence tuned) or where data is ephemeral (cache).

• Cache — offload hot data from Postgres/MySQL; set TTLs on keys
• Sessions — fast session storage with expiry
• Pub/sub — fire-and-forget messaging between services
• Queues — lists and streams for job buffers (often with a dedicated worker)
• Rate limiting — counters with INCR and TTL

How a client connection works

When an application connects, the typical workflow is:

1. TCP connect — client reaches host:6379 (or Unix socket)
2. Authentication — if requirepass or ACLs are set, client sends AUTH
3. Command loop — client issues Redis commands (RESP protocol); server executes single-threaded per shard
4. Response — result returns; connection stays open (pipelining supported)

Redis is single-threaded for command execution (per instance). One slow command blocks all others on that node — avoid KEYS * and unbounded SMEMBERS on large sets in production.

Key files and configuration

• /etc/redis/redis.conf — main config (path varies by distro)
• dir — directory for RDB and AOF files (e.g. /var/lib/redis/)
• bind — interfaces to listen on; default may be localhost only
• protected-mode — rejects external connections without auth when bind is open
• requirepass / ACL — authentication; prefer ACL users with least privilege (Redis 6+)
• Logs — logfile directive or systemd journal via redis-server service

Data structures

• Strings — SET, GET, counters with INCR
• Hashes — field/value maps, good for objects
• Lists — ordered sequences, queue-like patterns
• Sets / sorted sets — unique members; sorted sets for leaderboards
• Streams — append-only logs with consumer groups

Use SCAN (not KEYS) to iterate keys safely. Set TTL on cache keys so stale data expires automatically.

Memory and eviction

Redis holds all data in RAM. Set maxmemory to cap usage and choose an maxmemory-policy (e.g. allkeys-lru for cache, noeviction when every key must be retained — writes fail when full). Monitor with INFO memory and MEMORY STATS.

Persistence

Redis can survive restarts by writing data to disk. Two mechanisms, often combined:

RDB (snapshots) — point-in-time dumps triggered by save rules or BGSAVE. Compact and fast to restore; may lose writes since the last snapshot.

AOF (append-only file) — logs every write command. appendfsync everysec is a common balance. AOF can be rewritten (BGREWRITEAOF) to compact. Stronger durability than RDB alone.

If background save fails (disk full, permissions), Redis may refuse writes when stop-writes-on-bgsave-error yes (default) — check logs immediately.

Replication

A primary accepts writes; replicas receive a stream of commands and serve read-only copies. Replication is asynchronous — replicas can lag. Use INFO replication and ROLE to inspect state.

Basic setup (replica): in redis.conf set replicaof primary_host 6379 (older name: slaveof) and masterauth if the primary requires a password. Or at runtime: REPLICAOF host port.

Sentinel and Cluster (brief)

Redis Sentinel — monitors primaries and replicas, performs automatic failover when the primary is down. Clients use Sentinel for discovery.
Redis Cluster — shards data across multiple primaries (hash slots); each shard has its own replication. Required for horizontal scale beyond one node's RAM.

Backups

Replication is not a backup — a FLUSHALL on the primary propagates to replicas. Take independent backups of RDB/AOF files or trigger BGSAVE and copy the resulting dump.rdb.

For minimal disruption, copy the RDB after BGSAVE completes (LASTSAVE / INFO persistence). With AOF enabled, also back up appendonly.aof. Test restore on a staging instance. Managed services (ElastiCache, Redis Cloud) provide automated snapshots — know their retention.

Learning resources

• Redis documentation — redis.io/docs
• Configuration — redis.io — configuration
• Persistence — redis.io — persistence
• Replication — redis.io — replication
• ACL — redis.io — ACL