Redis hard
In a distributed Redis Cluster environment, how can a developer ensure that multiple keys always hash to the same physical node to enable multi-key operations?
- A By forcing the client to identify the master IP address and pinning all connection pools to that specific hardware socket.
- B By using curly braces `{}` (Hash Tags) in the key name; Redis only hashes the specific substring inside the braces.
- C By disabling the internal CRC16 hashing algorithm and using a manual modulo operation based on the current node count.
- D By creating a secondary global index that tracks the physical location of every key-value pair across all shards.
Answer: B. By using curly braces `{}` (Hash Tags) in the key name; Redis only hashes the specific substring inside the braces.
This provides manual control over data locality (Co-location). It ensures that related data (e.g., a user and their active orders) lives on the same shard, which is a hard requirement for executing Lua scripts or atomicity blocks on those keys.
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?