Eviction policies overview in Redis - Deep Dive

Overview - Eviction policies overview

What is it?

Eviction policies in Redis are rules that decide which data to remove when the database reaches its memory limit. Since Redis stores data in memory for fast access, it needs a way to free space when full. These policies help keep Redis running smoothly by removing some keys based on specific criteria. Without eviction policies, Redis would stop accepting new data once memory is full.

Why it matters

Memory is limited, and Redis is designed for speed by keeping data in memory. Without eviction policies, Redis would crash or refuse new data when memory is full, causing downtime or slow applications. Eviction policies ensure Redis can keep working by smartly removing less important data, balancing speed and memory use. This keeps apps responsive and reliable even under heavy load.

Where it fits

Before learning eviction policies, you should understand basic Redis concepts like keys, values, and memory usage. After this, you can explore advanced Redis features like persistence, replication, and performance tuning. Eviction policies fit into managing Redis memory and ensuring stable operation.

Mental Model

Core Idea

Eviction policies are like smart rules that decide which data Redis removes first when it runs out of memory.

Think of it like...

Imagine a backpack that can only hold so much. When it gets full, you decide what to take out: maybe old snacks, or things you use less often, to make room for new items. Eviction policies are the rules for what to remove from the backpack.

┌───────────────────────────────┐
│          Redis Memory          │
│  ┌───────────────┐            │
│  │   Data Keys   │            │
│  └───────────────┘            │
│  Memory Limit Reached? ───────┤
│            │                  │
│            ▼                  │
│  ┌─────────────────────────┐ │
│  │ Eviction Policy Rules   │ │
│  └─────────────────────────┘ │
│            │                  │
│            ▼                  │
│  ┌───────────────┐            │
│  │ Remove Keys   │            │
│  └───────────────┘            │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is Redis Memory Limit

Concept: Redis has a set maximum memory it can use, called the memory limit.

Redis stores all data in memory for fast access. To avoid using too much memory, Redis can be configured with a maximum memory limit. When Redis reaches this limit, it needs to decide what to do next.

Result

Redis knows when it is about to run out of memory and can trigger eviction policies.

Understanding that Redis has a memory limit is key to knowing why eviction policies are needed.

2

Foundation

Why Eviction Policies Exist

Concept: Eviction policies tell Redis how to free memory when the limit is reached.

When Redis hits its memory limit, it can't just stop working. Eviction policies are rules that tell Redis which keys to remove to free space. Without these rules, Redis would reject new data or crash.

Result

Redis can continue accepting new data by removing some old or less important data.

Knowing the purpose of eviction policies helps you understand their role in keeping Redis stable.

3

Intermediate

Common Eviction Policies Explained

🤔Before reading on: do you think Redis removes the oldest data first or the least used data first? Commit to your answer.

Concept: Redis offers several eviction policies like removing least recently used or random keys.

Redis supports multiple eviction policies: - noeviction: no keys are removed; new writes fail when memory is full. - allkeys-lru: removes least recently used keys from all keys. - volatile-lru: removes least recently used keys only from keys with expiration. - allkeys-random: removes random keys from all keys. - volatile-random: removes random keys only from keys with expiration. - volatile-ttl: removes keys with the shortest time to live. Each policy chooses keys differently to free memory.

Result

Redis removes keys based on the chosen policy, affecting which data stays or goes.

Understanding different policies helps you pick the best one for your app's needs.

4

Intermediate

How Expiration Affects Eviction

🤔Before reading on: do you think keys without expiration can be removed by all eviction policies? Commit to your answer.

Concept: Some eviction policies only remove keys that have an expiration time set.

Keys in Redis can have expiration times, meaning they automatically delete after some time. Policies like volatile-lru or volatile-random only remove keys that have expiration set. This lets you protect permanent keys from eviction. Policies with 'allkeys' in their name can remove any key regardless of expiration.

Result

You can control eviction scope by setting expiration on keys and choosing the right policy.

Knowing how expiration interacts with eviction policies lets you protect important data.

5

Intermediate

Configuring Eviction Policies in Redis

Concept: You set eviction policies in Redis configuration to control memory behavior.

In Redis, you configure eviction policies using the 'maxmemory-policy' setting in redis.conf or via the CONFIG SET command. For example, setting 'maxmemory-policy allkeys-lru' tells Redis to remove least recently used keys from all keys when memory is full. You also set 'maxmemory' to define the memory limit. These settings control how Redis behaves under memory pressure.

Result

Redis applies the chosen eviction policy automatically when memory is full.

Knowing how to configure eviction policies lets you tailor Redis to your application's needs.

6

Advanced

Eviction Policy Impact on Performance

🤔Before reading on: do you think eviction policies slow down Redis significantly? Commit to your answer.

Concept: Eviction policies can affect Redis performance depending on the policy and workload.

Some eviction policies like LRU require Redis to track key usage, which adds overhead. For example, allkeys-lru needs to maintain usage data for all keys, which can slow down writes slightly. Random eviction is faster but less precise. Choosing the right policy balances memory management and performance. Redis uses approximations for LRU to reduce overhead.

Result

Eviction policies influence Redis speed and resource use under heavy load.

Understanding performance trade-offs helps you pick policies that keep Redis fast and stable.

7

Expert

Surprises in Redis Eviction Behavior

🤔Before reading on: do you think Redis always frees enough memory immediately after eviction? Commit to your answer.

Concept: Redis eviction may not free memory instantly or perfectly due to internal details.

Redis eviction is approximate and may not free enough memory immediately because it samples a few keys to evict rather than scanning all keys. Also, some data structures or large keys may affect memory usage unpredictably. Eviction can trigger multiple times if memory is still full. Understanding these nuances helps troubleshoot memory issues and tune Redis effectively.

Result

Redis eviction is efficient but not perfect; tuning and monitoring are needed for best results.

Knowing eviction's approximate nature prevents false assumptions about memory behavior in production.

Under the Hood

Internally, Redis tracks key usage statistics to implement eviction policies like LRU. When memory limit is reached, Redis samples a small number of keys to find candidates for eviction instead of scanning all keys, which keeps eviction fast. For policies based on expiration, Redis checks TTL values. Eviction removes keys and frees memory, allowing new data to be stored. Redis uses an efficient data structure to track usage with minimal overhead.

Why designed this way?

Redis was designed for speed and simplicity. Full scans of all keys for eviction would be too slow. Sampling a few keys balances eviction accuracy and performance. Supporting multiple policies lets users choose based on their needs. The design avoids complex bookkeeping to keep Redis fast and lightweight.

┌───────────────┐
│ Memory Limit  │
│   Reached?    │
└──────┬────────┘
       │ Yes
       ▼
┌─────────────────────┐
│ Sample Keys (few)   │
│ Check Usage/TTL     │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Select Keys to Evict │
│ Remove Keys & Free   │
│ Memory              │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Accept New Writes    │
└─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Redis always remove the oldest key first when evicting? Commit to yes or no.

Common Belief: Redis always removes the oldest data first when memory is full.

Reality: Redis eviction depends on the policy; for example, LRU removes least recently used keys, not necessarily the oldest. Some policies remove random keys.

Why it matters: Assuming oldest keys are removed can lead to wrong expectations about which data stays, causing bugs or data loss.

Quick: Can eviction policies remove keys without expiration? Commit to yes or no.

Common Belief: Eviction policies only remove keys that have expiration set.

Reality: Only volatile-* policies remove keys with expiration. Allkeys-* policies can remove any key, even without expiration.

Why it matters: Misunderstanding this can cause important permanent keys to be evicted unexpectedly.

Quick: Does Redis eviction guarantee immediate memory freeing after removing keys? Commit to yes or no.

Common Belief: Eviction instantly frees enough memory to accept new data after removing keys.

Reality: Eviction is approximate and may require multiple rounds to free enough memory. Some keys may be large or complex, affecting memory usage unpredictably.

Why it matters: Expecting immediate memory freeing can cause confusion during troubleshooting and lead to wrong tuning decisions.

Quick: Is eviction policy configuration optional for Redis to work? Commit to yes or no.

Common Belief: Redis works fine without setting an eviction policy; it will never reject writes.

Reality: Without an eviction policy (noeviction), Redis rejects writes when memory is full, causing errors.

Why it matters: Not configuring eviction can cause application failures under memory pressure.

Expert Zone

1

Redis uses an approximate LRU algorithm that samples a few keys instead of tracking exact usage, balancing accuracy and performance.

2

Eviction policies interact with Redis persistence and replication, affecting data durability and consistency in subtle ways.

3

Large keys or complex data structures can cause uneven memory usage, making eviction behavior less predictable.

When NOT to use

Eviction policies are not suitable when data loss is unacceptable; in such cases, consider increasing memory, using Redis persistence, or sharding data. For write-heavy workloads with strict latency, random eviction may be better than LRU to reduce overhead.

Production Patterns

In production, allkeys-lru is commonly used for caching scenarios to keep most recently used data. Volatile-lru is used when only temporary keys should be evicted. Monitoring memory usage and eviction events is standard practice to tune policies and avoid unexpected data loss.

Connections

Cache Replacement Algorithms

Eviction policies in Redis implement cache replacement strategies like LRU and random.

Understanding cache algorithms helps grasp why Redis chooses certain keys to evict, improving memory management.

Operating System Virtual Memory Paging

Both Redis eviction and OS paging decide which data to remove from fast memory to free space.

Knowing OS paging concepts clarifies why Redis uses approximate methods instead of scanning all data.

Inventory Management in Retail

Eviction policies are like deciding which products to remove from shelves when space is limited.

This cross-domain link shows how managing limited resources with smart rules is a universal challenge.

Common Pitfalls

#1 Assuming Redis will never reject writes without eviction policy.

Wrong approach:

maxmemory-policy noeviction
maxmemory 100mb
# Expect Redis to accept all writes even when memory is full

Correct approach:

maxmemory-policy allkeys-lru
maxmemory 100mb
# Allows Redis to evict keys and accept new writes when memory is full

Root cause:

Misunderstanding that no eviction means Redis rejects writes on memory full.

#2 Setting volatile-lru policy but not setting expiration on keys.

Wrong approach:

maxmemory-policy volatile-lru
# Keys have no expiration set, so no keys are evicted

Correct approach:

Set expiration on keys with EXPIRE command
maxmemory-policy volatile-lru
# Eviction works on keys with expiration

Root cause:

Not realizing volatile policies only evict keys with expiration.

#3 Expecting eviction to free memory immediately after one key removal.

Wrong approach:

Assuming one eviction cycle frees enough memory for all new writes

Correct approach:

Monitor memory and eviction events; tune maxmemory and policy to handle multiple eviction cycles if needed

Root cause:

Not understanding eviction is approximate and may need multiple rounds.

Key Takeaways

Redis eviction policies control which keys are removed when memory is full to keep Redis running smoothly.

Different policies target keys based on usage, expiration, or randomness, allowing flexible memory management.

Eviction policies must be configured along with memory limits to avoid write failures under memory pressure.

Eviction algorithms are approximate to balance performance and accuracy, which can affect memory freeing behavior.

Understanding eviction policies helps prevent unexpected data loss and performance issues in Redis applications.