Redis medium
Why is executing the `KEYS *` command considered a high-risk operation in a production Redis cluster with millions of keys?
- A It automatically truncates any keys that do not strictly adhere to the internal UTF-8 encoding standard.
- B It generates an extremely large network payload that can saturate the local NIC the instance is running on.
- C It is an O(N) blocking operation that prevents all other client commands from running until scan completion.
- D It forces a full cluster-wide re-sharding event to occur, potentially leading to transient data inconsistency.
Answer: C. It is an O(N) blocking operation that prevents all other client commands from running until scan completion.
Redis is single-threaded. If `KEYS *` takes 2 seconds to scan the entire Keyspace, the server is dead to everyone else for those 2 seconds. Reliable production audits should always use the non-blocking `SCAN` command.
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?