Redis hard
Why might an administrator select the LFU (Least Frequently Used) eviction policy over the standard LRU (Least Recently Used) for a system with large periodic scans?
- A LFU uses a more efficient O(1) eviction logic that requires zero additional CPU overhead compared to LRU.
- B LFU is resistant to 'Scan Pollution'; one-time background scans won't displace frequently accessed 'hot' keys.
- C LFU reduces memory usage by automatically merging duplicate string keys into a single shared buffer segment.
- D LRU has been deprecated in Redis 6.0 and replaced by a more robust epoch-based frequency counter.
Answer: B. LFU is resistant to 'Scan Pollution'; one-time background scans won't displace frequently accessed 'hot' keys.
LRU only cares about the *last* access. A massive scan will touch every key, making them all 'Recent' and potentially evicting the real hot data. LFU uses a frequency counter, so a one-time touch won't outweigh 1,000 previous touches.
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?