Redis medium
What is the primary operational difference between the `volatile-lru` and `allkeys-lru` eviction policies in Redis?
- A `volatile-lru` only evicts keys with a TTL; `allkeys-lru` can evict any key regardless of expiration settings.
- B `volatile-lru` deletes keys that have been modified recently; `allkeys-lru` deletes keys that are static.
- C `allkeys-lru` is strictly restricted to String types, while `volatile-lru` can evict any complex data type.
- D There is no functional difference; both policies use a randomized sampling of the entire keyspace for speed.
Answer: A. `volatile-lru` only evicts keys with a TTL; `allkeys-lru` can evict any key regardless of expiration settings.
`volatile-lru` is crucial when you mix 'permanent' data (like config settings) and 'cache' data (like HTML snippets) in one instance. It ensures your critical config is never deleted to make room for ephemeral cache.
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?