Bird
Raised Fist0
Redisquery

Lua vs transactions comparison in Redis - Quick Revision & Key Differences

Choose your learning style10 modes available
Recall & Review
beginner
What is a Redis transaction?
A Redis transaction is a sequence of commands executed as a single atomic operation using MULTI and EXEC commands. All commands are queued and then executed together without interruption.
Click to reveal answer
beginner
What is a Lua script in Redis?
A Lua script in Redis is a small program written in Lua language that runs atomically on the Redis server, allowing complex operations to be executed in one step.
Click to reveal answer
intermediate
How does atomicity differ between Redis transactions and Lua scripts?
Both Redis transactions and Lua scripts execute atomically, but Lua scripts guarantee atomic execution of complex logic, while transactions only queue commands and execute them atomically without intermediate results.
Click to reveal answer
intermediate
Which method allows conditional logic and loops in Redis operations: transactions or Lua scripts?
Lua scripts allow conditional logic and loops because they run Lua code, while Redis transactions only queue commands without logic or loops.
Click to reveal answer
intermediate
What is a limitation of Redis transactions compared to Lua scripts?
Redis transactions cannot execute commands conditionally or perform complex logic inside the transaction, whereas Lua scripts can do both.
Click to reveal answer
Which Redis feature allows running multiple commands atomically with conditional logic?
ATransactions
BLua scripts
CPipelines
DPub/Sub
What command starts a Redis transaction?
AEVAL
BEXEC
CMULTI
DWATCH
Which of the following is true about Redis transactions?
AThey queue commands and execute atomically
BThey execute commands immediately
CThey support loops and conditionals
DThey run Lua code
What is the main advantage of Lua scripts over transactions in Redis?
AFaster network communication
BAutomatic retries
CSupport for multiple clients
DAbility to perform complex logic atomically
Which Redis command runs a Lua script?
AEVAL
BEXEC
CMULTI
DSCRIPT
Explain the differences between Redis transactions and Lua scripts in terms of atomicity and logic capabilities.
Think about what each can do inside the atomic block.
You got /4 concepts.
    Describe a scenario where using a Lua script is better than a Redis transaction.
    Consider when you want to do more than just queue commands.
    You got /4 concepts.

      Practice

      (1/5)
      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
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard