How to Choose Eviction Policies on Caching Database Clusters
Redis is an open source, key-value database built with an in-memory design that emphasizes speed. It has support for rich data types, atomic operations, and Lua scripting.
Caching stores its data, called keys, in memory only and uses eviction policies to free memory to write new data. Eviction policies fall into two main categories: general policies that apply to all keys and policies that use a Time to Live (TTL) expiration value. General policies consume less memory but require more CPU processing when Caching samples to choose which key to evict. TTL policies require you to set the TTL from your application. The extra TTL data consumes a bit more memory but TTL policies require less CPU processing when Caching is determining which keys to evict.
Tip
INFO command to reveal cache hits/misses to fine tune Caching.General Eviction Policies
General policies apply to any keys that do not have expiration set.
noeviction
noeviction Don’t evict any data, returns error when memory limit is reached. Default
With the noeviction policy set, Caching may stop responding if it runs out of memory but no data is ever evicted. This policy is generally appropriate only when your application removes keys itself. This is the Caching default setting and poses the least chance of data loss.
allkeys-lru
allkeys-lru Evict any key, least recently used (LRU) first. Recommended.
allkeys-lru helps keep Caching from becoming unresponsive due to insufficient memory and operates on the assumption that you no longer need the least recently used keys. When Caching begins to run out of memory, it samples a small set of keys using an algorithm, then evicts the least recently used key from that set. Because of the sampling algorithm, the key may not be the least recently used of all keys in memory.
allkeys-lfu
allkeys-lfu Evict any key, least frequently used (LFU) first.
allkeys-lfu helps keep Caching from becoming unresponsive due to insufficient memory and operates on the assumption that you no longer need the least frequently used keys. When Caching begins to run out of memory, it samples a small set of keys using an algorithm, then evicts the least frequently used key from that set. Because of the sampling algorithm, the key may not be the least frequently used of all keys in memory.
allkeys-random
allkeys-random Evict keys in a random order.
allkeys-random randomly evicts keys. It is appropriate for cases where your application continuously scans keys or no key is more important than any other key.
Eviction Policies Dependent on Expiration
These policies require that some keys have an expiration set.
volatile-lru
volatile-lru Evict keys with expiration only, least recently used (LRU) first.
This policy is similar to allkeys-lru. Caching evicts keys least recently used first, but only samples keys that are expired. This policy operates on the assumption that expired keys that are also least recently used are no longer required by your application.
volatile-lfu
volatile-lfu Evict keys with expiration only, least frequently used (LFU) first.
Caching evicts keys least frequently used first, but only samples keys that are expired. This policy operates on the assumption that expired keys that are also least frequently used are no longer required by your application.
volatile-random
volatile-random Evict keys with expiration only in a random order.
Similar to the allkeys-random policy, with this policy Caching evicts random keys but only those that have expired.
volatile-ttl
volatile-ttl Evict keys with expiration only, shortest time-to-live (TTL) first.
The volatile-ttl policy frees memory by evicting expired keys, regardless of when the key was last used. This policy allows you to tell Caching which keys are most important by explicitly setting an expiration value.
Learn more about Caching eviction policies in the official Redis documentation, Using Redis as an LRU cache