A Redis transaction is a way to execute a group of commands in sequence without interruption. It uses MULTI and EXEC commands to ensure all commands run together.
Click to reveal answer
beginner
What does a Lua script do in Redis?
A Lua script runs multiple commands atomically on the Redis server. It executes all commands as one block without other commands running in between.
Click to reveal answer
intermediate
How do Redis transactions differ from Lua scripts in terms of atomicity?
Redis transactions queue commands and run them sequentially but do not guarantee atomicity if commands read and write data. Lua scripts run all commands atomically, so no other commands run during the script.
Click to reveal answer
intermediate
Why might you choose a Lua script over a transaction in Redis?
You choose a Lua script when you need guaranteed atomic execution of multiple commands and want to avoid race conditions. Lua scripts also allow complex logic inside the server.
Click to reveal answer
intermediate
Can Redis transactions roll back if a command fails?
No, Redis transactions do not roll back if a command fails. All commands queued in MULTI are executed with EXEC, even if some fail. Lua scripts can handle errors inside the script.
Click to reveal answer
Which Redis feature guarantees atomic execution of multiple commands?
APub/Sub
BTransactions with MULTI/EXEC
CPipelines
DLua scripts
✗ Incorrect
Lua scripts run all commands atomically, ensuring no other commands run during execution.
What command starts a Redis transaction?
AEXEC
BWATCH
CMULTI
DEVAL
✗ Incorrect
MULTI starts a transaction by queuing commands until EXEC runs them.
If one command in a Redis transaction fails, what happens?
AAll commands run regardless of failure
BOnly the failed command is skipped
CThe entire transaction rolls back
DThe transaction retries automatically
✗ Incorrect
Redis transactions do not roll back; all commands run even if some fail.
Which Redis feature allows embedding complex logic inside the server?
ATransactions
BLua scripts
CPipelines
DSnapshots
✗ Incorrect
Lua scripts allow writing complex logic executed atomically on the server.
What is a key difference between Redis transactions and Lua scripts?
ALua scripts execute commands atomically, transactions do not guarantee atomicity
BTransactions can run scripts, Lua scripts cannot run transactions
CTransactions are atomic, Lua scripts are not
DBoth are identical in behavior
✗ Incorrect
Lua scripts execute all commands atomically; transactions queue commands but do not guarantee atomicity.
Explain the main differences between Redis transactions and Lua scripts.
Think about how commands run and whether they are atomic or not.
You got /5 concepts.
When would you prefer to use a Lua script instead of a Redis transaction?
2. Which of the following is the correct way to start a Redis transaction?
easy
A. EXEC
B. START TRANSACTION
C. BEGIN
D. MULTI
Solution
Step 1: Recall Redis transaction commands
Redis uses the command MULTI to start a transaction block.
Step 2: Identify the correct command
START TRANSACTION and BEGIN are SQL commands, not Redis. EXEC ends the transaction.
Final Answer:
MULTI -> Option D
Quick Check:
Start Redis transaction = MULTI [OK]
Hint: Use MULTI to start Redis transactions, EXEC to finish [OK]
Common Mistakes:
Using SQL commands like START TRANSACTION
Confusing EXEC as start command
Using BEGIN which is not Redis syntax
3. Given this Lua script in Redis:
local current = redis.call('GET', KEYS[1])
if not current then
redis.call('SET', KEYS[1], ARGV[1])
return ARGV[1]
else
return current
end
What will be the output if the key does not exist and ARGV[1] is "100"?
medium
A. Error
B. nil
C. "100"
D. "0"
Solution
Step 1: Analyze the Lua script logic
The script checks if the key exists. If not, it sets the key to ARGV[1] and returns ARGV[1].
Step 2: Apply the input values
Since the key does not exist, it sets the key to "100" and returns "100".
Final Answer:
"100" -> Option C
Quick Check:
Key missing sets and returns ARGV[1] = "100" [OK]
Hint: If key missing, Lua sets and returns ARGV[1] [OK]
Common Mistakes:
Assuming nil is returned when key missing
Expecting an error from redis.call
Confusing return values with zero
4. You wrote this Redis transaction:
MULTI
SET key1 foo
INCR key1
EXEC
But the INCR command fails with an error. What is the likely cause?
medium
A. SET sets key1 as a string, INCR expects an integer value
B. INCR cannot be used inside MULTI blocks
C. EXEC was missing to run the transaction
D. MULTI command syntax is incorrect
Solution
Step 1: Understand SET and INCR behavior
SET stores the value as a string. INCR expects the key to hold an integer value.
Step 2: Identify the error cause
Since SET sets "foo" as a string, INCR fails because it cannot increment a non-integer string.
Final Answer:
SET sets key1 as a string, INCR expects an integer value -> Option A
Quick Check:
INCR needs integer, SET stores string [OK]
Hint: INCR needs integer; SET stores string by default [OK]
Common Mistakes:
Thinking INCR can't be in MULTI
Forgetting to EXEC the transaction
Assuming MULTI syntax is wrong
5. You want to atomically check if a key exists and increment it only if it does, otherwise set it to 1. Which approach is best in Redis?
hard
A. Use a Lua script that checks and updates the key atomically
B. Use Redis pipeline to send GET and INCR commands together
C. Run separate GET and INCR commands without transactions
D. Use a Redis transaction with WATCH, GET, and MULTI commands
Solution
Step 1: Understand the atomicity requirement
The operation must be atomic: check existence and update in one step without race conditions.
Step 2: Compare approaches
Transactions with WATCH can be complex and may fail due to race conditions. Separate commands or pipelines are not atomic. Lua scripts run atomically inside Redis and can handle logic safely.
Final Answer:
Use a Lua script that checks and updates the key atomically -> Option A
Quick Check:
Atomic check and update = Lua script [OK]
Hint: Use Lua scripts for atomic logic beyond simple transactions [OK]
Common Mistakes:
Assuming WATCH transactions are always safe
Using separate commands risking race conditions
Confusing pipelines with atomic execution
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.