Knowing Redis's model (in-memory, single-threaded commands, typed values) explains every design choice that follows.
Redis is a server that stores keys mapped to values, all in RAM. Unlike a plain cache, the values are typed data structures: strings, hashes, lists, sets, sorted sets, streams, and more. You manipulate them with commands such as SET, HSET, LPUSH or ZADD, sent over TCP with a simple protocol (RESP).
Because everything lives in memory and commands are executed one at a time by a single main thread, operations take microseconds and every individual command is atomic: no other client's command runs halfway through yours. Redis can still persist data to disk and replicate it, but it is designed around the assumption that the dataset fits in memory.
redis-cli is the command-line client. Run it with no arguments for an interactive prompt, or pass a command directly: redis-cli SET greeting hello. Useful basics:
PINGrepliesPONG,SELECT 1switches among numbered logical databases (default 0),KEYS *lists keys but blocks the server on big datasets; useSCANinstead,TYPE keytells you the data type,FLUSHDBdeletes everything in the current database.
Key names are binary-safe strings; the convention is colon-separated namespaces like user:42:profile. Redis is commonly used beside a primary database, not instead of one.
Example
redis-cli PING # PONG
redis-cli SET user:42:name "Ana" # OK
redis-cli GET user:42:name # "Ana"
redis-cli TYPE user:42:name # string
redis-cli EXISTS user:42:name user:7 # (integer) 1
redis-cli DBSIZE # (integer) 1
redis-cli GET missing # (nil)Remember
- Keys map to typed data structures, all held in RAM
- Each command is atomic; commands run one at a time
- Use namespaced keys like user:42:profile
- Avoid KEYS * in production; it blocks the server
Watch out for
- Running KEYS * on a production instance with millions of keys and stalling every client.