Redis medium
Redis transactions (`MULTI/EXEC`) do not support rollback. How does the `WATCH` command address data integrity during concurrent updates?
- A It acquires a Pessimistic Lock on the key, blocking all other clients until the transaction finishes.
- B It implements Optimistic Locking by aborting the transaction if the watched key is modified externally.
- C It creates a temporary in-memory clone of the entire database to ensure total snapshot isolation.
- D It forces all other connections to wait in a global kernel-level semaphore queue until `EXEC` is called.
Answer: B. It implements Optimistic Locking by aborting the transaction if the watched key is modified externally.
`WATCH` allows Check-And-Set (CAS) semantics. If you watch a value, calculate an update, and someone else changes that value before you commit, the `EXEC` returns a Null multi-bulk to signal failure.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- If the Redis memory limit is reached, what specific behavior is exhibited by the `allkeys-lru` eviction policy?
- What is the defining characteristic of a Redis 'Set' data type compared to a standard Redis 'List'?
- In the context of Redis messaging, what is the functional definition of the 'Pub/Sub' feature?
- How does the Redis background snapshotting process (`BGSAVE`) leverage the operating system's `fork()` mechanism to minimize memory overhead?
- Why does Redis proactively disconnect a Pub/Sub client that exhibits high 'output buffer' usage relative to its ingestion rate?
- How does a 'Sorted Set' (ZSET) manage its internal membership and ordering differently from a plain Set?