Lua vs transactions comparison in Redis - Visual Side-by-Side Comparison

Concept Flow - Lua vs transactions comparison

Start Client Command

↓

Choose: Use Lua Script?

No→Use MULTI/EXEC Transaction

↓

Queue Commands

↓

Run Lua Script Atomically

↓

EXEC Executes All

↓

Atomic Execution Complete

↓

Return Result to Client

This flow shows how Redis handles atomic operations either by running a Lua script atomically or by queuing commands in a MULTI/EXEC transaction.

Execution Sample

Redis

MULTI
SET key1 100
INCR key1
EXEC

This Redis transaction queues commands and executes them atomically with EXEC.

Execution Table

Step	Action	Command	State Before	State After	Result
1	Start Transaction	MULTI	key1 does not exist	Transaction started	OK
2	Queue Command	SET key1 100	Transaction started	SET queued	QUEUED
3	Queue Command	INCR key1	SET queued	INCR queued	QUEUED
4	Execute Transaction	EXEC	Commands queued	key1=101	["OK", 101]
5	End	N/A	Transaction executed	No active transaction	N/A

💡 EXEC runs all queued commands atomically, then transaction ends.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
key1	NULL	NULL	NULL	101	101
Transaction State	None	Started	Started	Executed	None

Key Moments - 2 Insights

Why does the key1 value only change after EXEC?

Commands are only queued during MULTI; actual changes happen atomically when EXEC runs, as shown in execution_table step 4.

How is Lua script execution different from MULTI/EXEC?

Lua scripts run all commands atomically in one go without queuing, unlike MULTI/EXEC which queues commands before execution.

Visual Quiz - 3 Questions

Look at the execution_table at step 3, what is the state of the transaction?

A Transaction executed

B No active transaction

C Transaction started and commands queued

D Transaction aborted

💡 Hint

Refer to execution_table row 3, 'State After' column shows 'INCR queued'.

At which step does key1 get its new value?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Check execution_table step 4, 'State After' shows 'key1=101'.

If we replace MULTI/EXEC with a Lua script doing the same commands, what changes?

A Commands execute atomically without queuing

B Commands are queued before execution

C Commands execute one by one with delays

D Commands cannot modify keys

💡 Hint

See key_moments explanation about Lua scripts running atomically in one go.

Concept Snapshot

Redis MULTI/EXEC queues commands and runs them atomically on EXEC.
Lua scripts run all commands atomically in one execution without queuing.
MULTI/EXEC is multi-step; Lua script is single-step atomic.
Both ensure atomicity but differ in execution style and complexity.
Use Lua for complex logic; MULTI/EXEC for simple grouped commands.

Full Transcript

This visual execution compares Redis Lua scripts and MULTI/EXEC transactions. MULTI starts a transaction, queues commands like SET and INCR, then EXEC runs all queued commands atomically, updating key1 from NULL to 101. Lua scripts run all commands atomically in one step without queuing. The key difference is that MULTI/EXEC separates queuing and execution, while Lua scripts execute all logic in one atomic call. This ensures atomicity in both but with different workflows. Beginners often confuse when changes happen in MULTI/EXEC; changes only apply at EXEC. Lua scripts simplify atomic execution by running all commands together. This comparison helps understand when to use each method in Redis.

Practice

1. Which statement best describes the difference between Lua scripts and transactions in Redis?

easy

A. Transactions are faster and more flexible than Lua scripts.

B. Transactions can execute complex logic, Lua scripts only group commands.

C. Lua scripts allow complex logic, while transactions group simple commands atomically.

D. Both Lua scripts and transactions cannot guarantee atomic execution.

Solution

1. Step 1: Understand atomic execution in Redis

   Both Lua scripts and transactions ensure commands run atomically, meaning all commands execute as one unit without interruption.

2. Step 2: Compare complexity and usage

   Lua scripts allow embedding complex logic and multiple commands in one script, while transactions simply group commands without logic.

3. Final Answer:

   Lua scripts allow complex logic, while transactions group simple commands atomically. -> Option C

4. Quick Check:

   Lua = complex logic, transactions = simple groups [OK]

Hint: Lua = complex logic, transactions = simple command groups [OK]

Common Mistakes:

• Thinking transactions can run complex logic
• Believing Lua scripts do not guarantee atomicity
• Confusing speed differences between Lua and transactions

2. Which of the following is the correct way to start a transaction in Redis?

easy

A. MULTI

B. EVAL

C. EXEC

D. SCRIPT

Solution

1. Step 1: Recall Redis transaction commands

   Redis transactions start with the MULTI command to begin queuing commands.

2. Step 2: Identify correct command usage

   EXEC is used to execute queued commands, EVAL runs Lua scripts, SCRIPT manages scripts, so MULTI is the correct start.

3. Final Answer:

   MULTI -> Option A

4. Quick Check:

   Start transaction with MULTI [OK]

Hint: Start transactions with MULTI, execute with EXEC [OK]

Common Mistakes:

• Using EXEC to start a transaction
• Confusing EVAL with transaction commands
• Using SCRIPT to start transactions

3. Given the following Lua script executed in Redis:

local val = redis.call('GET', KEYS[1])
if val == nil then
  redis.call('SET', KEYS[1], ARGV[1])
  return ARGV[1]
else
  return val
end

What will be the output if the key does not exist and ARGV[1] is "hello"?

medium

A. Error

B. nil

C. false

D. "hello"

Solution

1. Step 1: Check key existence with redis.call('GET')

   If the key does not exist, redis.call('GET') returns nil in Lua script context.

2. Step 2: Set key and return ARGV[1]

   Since val == nil, the script sets the key to ARGV[1] which is "hello" and returns "hello".

3. Final Answer:

   "hello" -> Option D

4. Quick Check:

   Key missing sets and returns ARGV[1] = "hello" [OK]

Hint: If key missing, Lua script sets and returns ARGV[1] [OK]

Common Mistakes:

• Thinking GET returns false instead of nil
• Expecting nil or error instead of returned value
• Confusing Lua false with Redis nil

4. You wrote this Redis transaction:

MULTI
GET key1
SET key1 value1
EXEC

But the GET command returns nil instead of "value1". What is the likely cause?

medium

A. GET command syntax is incorrect

B. GET runs before SET executes in transaction

C. EXEC was not called to execute commands

D. Redis transactions do not guarantee atomicity

Solution

1. Step 1: Understand Redis transaction command queuing

   Commands inside MULTI are queued and executed only after EXEC; GET does not see SET effect during queuing.

2. Step 2: Explain why GET returns nil

   GET is queued before SET, so during EXEC it executes first and returns nil because SET has not been applied yet.

3. Final Answer:

   GET runs before SET executes in transaction -> Option B

4. Quick Check:

   Queued commands run after EXEC, GET sees old value [OK]

Hint: Queued commands run after EXEC; GET sees old value during queue [OK]

Common Mistakes:

• Thinking commands run immediately inside MULTI
• Assuming GET syntax error causes nil
• Believing EXEC was not called

5. You want to atomically increment a counter only if its current value is less than 10. Which approach is best in Redis?

hard

A. Use a Lua script to check and increment atomically

B. Use MULTI/EXEC transaction with GET and INCR commands

C. Run GET and INCR commands separately in client code

D. Use WATCH on the key and then INCR without Lua

Solution

1. Step 1: Understand atomic conditional increment need

   Increment only if value < 10 requires checking and updating atomically to avoid race conditions.

2. Step 2: Compare Lua script vs transactions

   Lua scripts run all logic atomically in Redis, while transactions cannot conditionally check and increment atomically without race.

3. Step 3: Evaluate WATCH option

   WATCH can detect changes but requires retry logic and is less clean than Lua script for this logic.

4. Final Answer:

   Use a Lua script to check and increment atomically -> Option A

5. Quick Check:

   Lua scripts handle complex atomic logic best [OK]

Hint: Use Lua for atomic conditional logic, transactions can't do it alone [OK]

Common Mistakes:

• Assuming transactions can do conditional increments atomically
• Ignoring race conditions with separate GET and INCR
• Overestimating WATCH simplicity without retries