Locking, Streams & Scripting

Preview — 3 of 10 questions

Why must the NX and EX options be in the same SET command for a correct distributed lock?

AUsing separate commands is slightly slower but functionally equivalent

BSETNX + EXPIRE is actually safer because Redis rolls back EXPIRE if the server crashes

CSET key value NX EX seconds is atomic at the server level; using separate SETNX then EXPIRE creates a race window where a crash between the two commands leaves the key without a TTL, permanently blocking other lock acquisitions (deadlock)

DThe NX and EX options cannot both be specified in one command — Redis requires two commands

What problem does the Redlock algorithm solve that a single-node Redis lock cannot?

AA single-node Redis lock fails entirely if that Redis instance crashes; Redlock acquires locks on N independent Redis masters (N=5 recommended) — the lock is valid only if acquired on a majority (≥N/2+1), providing fault tolerance if a minority of nodes fail

BRedlock allows multiple clients to hold the same lock simultaneously for read-only operations

CRedlock adds a token bucket rate limiter to prevent lock starvation

DRedlock solves the problem of multiple keys needing to be locked atomically

What is the behavior of a Redis MULTI/EXEC block when one command inside it encounters an error?

ARedis rolls back all previously executed commands in the block (like SQL ROLLBACK)

BFor syntax/type errors detected at queue time, the entire EXEC is aborted; for runtime errors (e.g., wrong type), only the failing command returns an error — other commands in the block still execute successfully (no rollback)

CAll commands after the error are skipped, but commands before it are committed

DMULTI/EXEC always provides full ACID guarantees including rollback

Answer all 10 questions (7 more), see explanations for every answer, and track your score.