Redis commands, exam-style

Strings, keys and the counter that cannot lose

Every Redis command names a key and says what to do with the value stored under it. The simplest value is a string: a piece of text or a number. The session stores one with SET and reads it with GET; for reading, "The only requirement is that we need to know the key_name" (p. 1582). The lecture runs the pair on the key foo (p. 355):

redis> SET foo "hello!"
OK
redis> GET foo
"hello!"

Read it as a conversation. SET answers OK and silently replaces whatever the key held; GET answers the value in quotes, or (nil) when there is no such key. A key or a value with spaces goes in double quotes: the exam of 24 June 2024 wants a key named "Line #0001" with the value "A long time ago in a galaxy far, far away". The slides print typographic quotes (“hello!“); type straight ones.

Four commands work on a whole key, whatever its type (p. 356, pp. 1583–1584). EXISTS "returns a value of 1 if the field exists, 0 otherwise"; DEL removes the key and answers how many keys it removed; TYPE names the structure under the key; RENAME moves the value to a new name.

redis> EXISTS foo
(integer) 1
redis> TYPE foo
string
redis> RENAME foo greeting
OK
redis> GET greeting
"hello!"
redis> DEL greeting
(integer) 1
redis> EXISTS greeting
(integer) 0
redis> GET greeting
(nil)

The lecture adds four helpers (p. 355). MSET and MGET write and read several keys in one round trip, STRLEN gives the length, and GETSET stores a new value and hands back the old one. The slide leaves out the reply of GETSET: it is the old value, "hello!".

redis> MSET foo "hello!" bar 1223
OK
redis> MGET foo bar
1) "hello!"
2) "1223"
redis> STRLEN foo
(integer) 6
redis> GETSET foo "bye!"
"hello!"

Look at "1223": it comes back in quotes. Redis keeps every number as a string and reads it as an integer only when a command needs one.

Counting, and the update that gets lost

Strings that hold integers can count. The session lists four commands (p. 1585): "INCR – Increases the value by 1", "DECR – Decreases the value by 1", "INCRBY – Increases the value by the amount set", "DECRBY – Decreases the value by the amount set". A missing key counts as 0, so the first INCR of a new counter answers 1; a value that is not an integer, like the "bye!" now in foo, gets an error:

redis> INCR visits
(integer) 1
redis> DECR visits
(integer) 0
redis> DECRBY visits 5
(integer) -5
redis> INCR foo
(error) ERR value is not an integer or out of range

The lecture's example (p. 355) adds a thousand in one step:

redis> SET bar 223
OK
redis> INCRBY bar 1000
(integer) 1223

Then the session asks a fair question. A client could add one with the commands it already has (p. 1586):

> x = GET key_name
  x = x + 1
  SET key_name x

"The proposed script is a general way of executing the increasing or decreasing operations. Then, why do we need them?" The answer is an animation (pp. 1588–1593). Two clients both GET 10, both compute 11 on their own side, both SET 11. Two increments were asked for, the counter moved by one, and the slide ends in red: "Using the script will cause these two increases to be applied incorrectly!" This is the lost update.

Why is INCR atomic when the three lines are not? The three lines are three trips: a read, a sum on the client, a write. Between the read and the write lies a gap, and another client's read or write can fall into it. INCR does the read, the +1 and the write inside the server, in one command — and the server runs one command at a time. The lecture says it in two lines (p. 352): "Redis is a single-threaded server", and "All operations are atomic (no two commands can run at the same time)". No lock is involved: while a command runs, nothing else runs.

An increment is safe only when its read and its write happen inside one command.

You know the same cure from SQL: UPDATE counters SET value = value + 1 lets the database do the sum instead of the client. One command gets the isolation that lesson 3 asked of a whole transaction.

Keys with a lifetime

Redis often works as a cache, and a cache has to forget on its own: a session nobody uses, a page that went stale. So any key can carry a clock. The session calls such pairs "temporary key-value pairs" and gives two commands (p. 1594): "EXPIRE – Set the lifespan of a variable (in seconds)" and "TTL – Returns the remaining lifespan of a variable (in seconds)". On the lecture slide (p. 356):

redis> EXPIRE foo 10
(integer) 1
redis> TTL foo
(integer) 10

EXPIRE answers 1 when it armed the clock and 0 when the key does not exist. "PEXPIRE and PTTL achieves the same operations in milliseconds" (p. 1594) — fine enough to show the time you spent typing:

redis> PEXPIRE foo 60000
(integer) 1
redis> PTTL foo
(integer) 58904

When the clock reaches zero, Redis deletes the key exactly as DEL would: the whole key, whatever it holds.

TTL answers in three ways, and the exam's "check its lifespan" is about them (p. 1595): the remaining seconds; "-1 – The key will never expire"; "-2 – The key has already expired". Read -2 as "there is no such key": Redis gives the same answer for a key that expired, was deleted or never existed. The three answers are three states of a key, and a handful of commands move a key between them.

The first move is a shortcut: SET takes the lifetime as an option, so the value and the clock arrive in one command (p. 1595). It is the natural answer to "Create a key-value pair with "best_book", the value "La ragazza delle Arance", and TTL equal to 100" (exam of 21 January 2025):

redis> SET best_book "La ragazza delle Arance" EX 100
OK

The next sentence of the slide hides a trap: "whenever the key is SET, the TTL is reset". Reset means removed, not restarted. A plain SET replaces the value and throws the clock away, and the key becomes permanent:

redis> SET k "v" EX 100
OK
redis> SET k "w"
OK
redis> TTL k
(integer) -1

Commands that change a value in place — INCR, LPUSH, SADD, HSET — leave the clock alone, and RENAME takes it along to the new name (Redis documentation, background). The last move removes a clock on purpose: "The PERSIST operator can be used to solve such a problem. It permanently stores a temporary variable in the database" (p. 1596). It answers 1 when it removed a timeout and 0 when there was none:

redis> PERSIST best_book
(integer) 1
redis> TTL best_book
(integer) -1

Lists: two ends and inclusive indexes

A list is a sequence of strings in a fixed order, duplicates allowed. You build it from either end (p. 1597): "RPUSH – Puts one or more new elements at the end of the list" and "LPUSH – Puts one or more new elements at the beginning of the list". "If the key does not exist, it will be created. A key with an empty list will be automatically deleted." Both commands answer the length of the list after the push. Here is the lecture's list of jobs (p. 357), with the replies Redis really gives:

redis> RPUSH jobs "foo"
(integer) 1
redis> LPUSH jobs "bar"
(integer) 2
redis> LRANGE jobs 0 -1
1) "bar"
2) "foo"

With several values in one command, the two ends behave differently. RPUSH appends them one by one at the tail, so they keep the order you typed. LPUSH puts them one by one at the head, each in front of the previous one, so the order comes out reversed.

That settles the exam of 24 June 2024, "create a new list of lines involving the lines "Hey you", "Watch out", and "Hello there"": with RPUSH the first line typed is the first line stored.

Reading a range

"The LRANGE operator can be used to retrieve a subset of values from a list" (p. 1598), written LRANGE key first_index last_index. Three rules decide what comes back. Indexes start at 0. A negative index counts from the end: -1 is the last element, -2 the one before it. And both ends are included — unlike a Python slice, where l[0:2] stops before index 2.

redis> RPUSH lines "Hey you" "Watch out" "Hello there"
(integer) 3
redis> LRANGE lines 0 2
1) "Hey you"
2) "Watch out"
3) "Hello there"

The slide puts the negative stop another way: "Negative numbers (e.g., -N) mean that the operator will return all values besides the last N-1 values (e.g., -2 means that we are collecting all the elements, besides the last one)". It is the same rule counted from the tail: in a list of L elements, a stop of -N is position L − N.

Taking elements out: queues and stacks

"LPOP – Removes the first item of the list and returns it", "RPOP – Removes the last item of the list and returns it", and LLEN gives the length (p. 1599). LINDEX key index reads one element without removing it (p. 357). Combine the ends and you get the two classic structures: RPUSH with LPOP is a queue, first in first out; LPUSH with LPOP is a stack, last in first out.

redis> RPUSH q "job1" "job2" "job3"
(integer) 3
redis> LINDEX q 1
"job2"
redis> LPOP q
"job1"
redis> RPOP q
"job3"
redis> LLEN q
(integer) 1

Two list commands are made for job queues (p. 357). RPOPLPUSH src dst pops the last element of one list and pushes it onto the head of another in one atomic step: the slide moves "foo" from jobs to proc, and at every moment the job sits in one of the two lists. BLPOP and BRPOP are blocking pops: on an empty list the client waits until an element arrives or the timeout runs out — the "Blocking queues" among the use cases of the lecture (p. 350). On the list jobs above, the reply names the list, because one command can watch several:

redis> BLPOP jobs 0
1) "jobs"
2) "bar"

Membership is where a list is weak. "Check whether the animal "Bob" is in a list of animals named "Farm"" (exam of 12 September 2025) has no list command on the slides: you read the whole list with LRANGE Farm 0 -1, or ask LPOS Farm "Bob" (Redis 6.0.6 and later, background), which answers the position or (nil). Both walk the list — the slide marks LINDEX and LRANGE O(N), in red. When the question is "is X in there?", the structure made for it is a set.

Sets, sorted sets and hashes

A set drops the order and the duplicates: "SETS are similar to lists, but they don't have a specific value order, and each value can only appear once per set. SETS are useful as it is very quick to test the existence of a value, which is not as easy when it comes to lists" (p. 1600). Its commands start with S. SADD and SREM add and remove members, SISMEMBER "Returns 1 if the value is part of the set, 0 otherwise", SMEMBERS "Returns all the members in the set" (p. 1601), and SCARD, which the slides do not show, counts them.

redis> SADD instruments "Keyboard" "Violin" "Drums"
(integer) 3
redis> SADD instruments "Violin"
(integer) 0
redis> SISMEMBER instruments "Flute"
(integer) 0
redis> SREM instruments "Drums" "Piano"
(integer) 1
redis> SCARD instruments
(integer) 2
redis> SMEMBERS instruments
1) "Keyboard"
2) "Violin"

Sets also combine. The lecture's example (p. 358) has users = {John, Peter} and admins = {Peter}:

redis> SADD admins "Peter"
(integer) 1
redis> SADD users "John" "Peter"
(integer) 2

redis> SINTER users admins
1) "Peter"
redis> SUNION users admins
1) "John"
2) "Peter"
redis> SDIFF users admins
1) "John"

A set has no order, so Redis may list the members of a reply in any order — the slide got "Peter" first. "SUNION – Combines two or more sets into one set" (p. 1601) returns the union without storing it; SUNIONSTORE dest key1 key2 keeps it under a new key (background). SPOP removes and returns a random member (p. 358). The SINTER box of p. 358 is in the slide's text but hidden under another box on the rendered page; its example is the one above.

Sorted sets: a set with a score

"Since sets are not ordered, Redis introduced the concept of an ORDERED SET. In an ORDERED SET, each element of the set is assigned to a score that is used to define the order in the set" (p. 1602). The lecture slide calls it a sorted set (p. 358), and so do the Redis docs: two names, one structure. Members stay unique, as in a set; the score, a floating-point number, decides their place, lowest first, and equal scores go in alphabetical order.

redis> ZADD scores 100 "John"
(integer) 1
redis> ZADD scores 50 "Peter" 200 "Charles" 1000 "Mary"
(integer) 3

The score comes first, ZADD key score member, with as many pairs as you like, and the reply counts the new members. ZRANGE key start stop (p. 1602) reads by position in score order, with the inclusive, negative-friendly indexes of LRANGE; add WITHSCORES to see the scores, and REV (Redis 6.2 and later, background) to start from the highest.

redis> ZRANGE scores 0 -1 WITHSCORES
1) "Peter"
2) "50"
3) "John"
4) "100"
5) "Charles"
6) "200"
7) "Mary"
8) "1000"
redis> ZRANGE scores 0 0 REV
1) "Mary"

redis> ZRANK scores "Mary"
(integer) 3
redis> ZRANGEBYSCORE scores 200 +inf WITHSCORES
1) "Charles"
2) "200"
3) "Mary"
4) "1000"
redis> ZINCRBY scores 10 "Mary"
"1010"
redis> ZREMRANGEBYSCORE scores 0 100
(integer) 2

Every sorted-set reply on p. 358 checks out. Ranks start at 0, so Mary, the highest of four, has rank 3. ZRANGEBYSCORE includes its bounds and accepts +inf. ZINCRBY answers the new score, as a string. The range 0–100 removes Peter (50) and John (100). This is the structure behind "Create a list to store all Department specialties, sorted by their foundation year. Then, query the list to get the older one" (exam of 30 January 2026): the year is the score, and the oldest is ZRANGE key 0 0. It is also how you would keep the best checkpoint of a training run: the validation loss as the score, and rank 0 is the model to keep.

Hashes: one object under one key

"HASHES are mappings between string fields and string values" (p. 1603): a small dictionary under one key, much like a Python dict. That makes a hash the home of one object and its attributes. The key carries the type and the id of the object — user:1 on p. 357 — and each attribute becomes a field:

redis> HSET user:1 name John
(integer) 1
redis> HMSET user:1 lastname Smith visits 1
OK
redis> HGET user:1 name
"John"
redis> HGETALL user:1
1) "name"
2) "John"
3) "lastname"
4) "Smith"
5) "visits"
6) "1"

HSET takes several field–value pairs in one command (p. 1603) and answers how many fields are new; the lecture's HMSET (p. 357) is the older spelling and still works. HGETALL answers one flat list: field, value, field, value. HINCRBY keeps a counter inside the object, atomic like INCR:

redis> HINCRBY user:1 visits 1
(integer) 2

A clock still belongs to the whole key. HSET has no EX option, so "a single key-value pair to store all the data of one Gas Heater, with a TTL of 100" (30 January 2026) takes two commands, HSET then EXPIRE. Type EX 100 at the end of an HSET and Redis raises no error: it stores a field called "EX" with the value "100", and the key never expires.

From the exam sentence to the commands

Five of the nine past papers have a Redis exercise, and the 2026/27 rules name Redis among the topics of the practical part. Each of the five starts from an entity of the paper's ER diagram, is worth 3 to 5 points in items of 1 or 2, and asks for the same two moves: recognise the structure in the wording, then write its commands. The table collects the phrases of all five.

Two habits help beyond the commands. Name the keys after the entity of the diagram, and quote anything with a space. And when a sentence asks for something Redis cannot do word for word, write the closest commands and add one sentence on what Redis does instead: the readme of the past papers warns that "Exams might include minor typos" and asks you to "consider all the necessary assumptions to solve the exercise".

What each command costs

Next to every command the slides print its cost. The lecture sums it up as "It executes most commands in O(1) complexity" (p. 352); the table sorts the commands of pp. 355–358 by the cost printed beside them.

The pattern has a reason (Redis documentation, background). A key is found by hashing, so anything that touches one key and one element is O(1). A list is linked, so its two ends are cheap and its middle is not: LINDEX and LRANGE walk it. A set is a hash table, so SISMEMBER is O(1) where a list scan is O(N). A sorted set keeps its members in order in a skip list, so inserting and finding by score take O(log(N)). Commands that hand back a whole structure, SMEMBERS or HGETALL, are O(N) in its size.

A Redis to try things on

Reading replies is one skill; predicting them is the one the exam needs. The console below runs a small Redis inside this page, with every command of this lesson, and replays the slides' sessions and the five papers one line at a time.

The flute, settled

Back to the hook. Eleven seconds after EXPIRE instruments 10, SISMEMBER instruments "Keyboard" answers 0. The clock was armed on the key instruments; at t = 10 s Redis deleted the key, and with it every member — Keyboard, Violin and Drums as well as Flute. TTL instruments now answers -2.

So the safe answer is two commands and one sentence: SADD instruments "Flute", EXPIRE instruments 10, and "in Redis a TTL belongs to a key, so the whole set expires after 10 seconds; a single member cannot have its own". If only Flute should go, it needs a key of its own, such as SET instrument:Flute "Flute" EX 10. What must not be written is SADD instruments "Flute" EX 10: SADD has no options, and Redis adds two more members, "EX" and "10".

A TTL belongs to a key, never to one member of a list, a set or a sorted set.