Exploring Redis Configuration

How can a simple in-memory key-value store dramatically speed up your entire application?

Objectives & Success Criteria

By the end of this lesson, you will be able to:

  • Analyze hardware needs for a given Redis use case.
  • Configure key security and memory directives in `redis.conf`.
  • Explain the difference between RDB and AOF persistence.
  • Implement the Cache-Aside pattern in application code.
  • Select an appropriate memory eviction policy.

Lesson Roadmap

A horizontal timeline of the lesson's topics. Hardware Sizing Core Config redis.conf Persistence RDB vs AOF Caching TTL & Eviction Strategies Cache-Aside

Core Idea: Hardware Sizing

Redis performance is fundamentally tied to its hardware. Prioritize plentiful RAM for the dataset, high single-core CPU speed for command processing, low-latency networking for client communication, and fast storage (SSD) only if persistence is required.

Redis Hardware Interaction Diagram Redis Hardware Ecosystem Redis Server Single-threaded event loop Background I/O threads Memory (RAM) 1. Holds 100% of dataset. 2. Sizing: >1.5x data size. 3. Watch for CoW spikes. CPU Primary Goal: High single-core speed. Secondary: Cores for background tasks. Network Primary Goal: Minimize latency (RTT). Secondary: High bandwidth (Gbps). Storage (Disk) Only for persistence (RDB/AOF). SSD is highly recommended. Irrelevant if persistence is off.

Core Idea: The `redis.conf` File

The `redis.conf` file is the central nervous system of your Redis instance. It's a plain text file where you define critical behaviors, including network bindings, security rules, memory limits, and data persistence strategies.

Diagram showing directives from redis.conf configuring a Redis instance. Controlling Redis via redis.conf /etc/redis/redis.conf bind 127.0.0.1 requirepass ... maxmemory 2gb maxmemory-policy allkeys-lru save 900 1 appendonly no logfile /var/log/redis.log loglevel notice Redis Instance Security & Network Who can connect, and how? Memory How much? What to evict? Persistence How is data saved? Logging & Ops Where do logs go?

Core Idea: Persistence (RDB vs. AOF)

Persistence saves your in-memory data to disk, ensuring durability across restarts. RDB creates point-in-time snapshots (fast, compact), while AOF logs every write command (more durable, potentially larger file).

RDB vs AOF Persistence Comparison Redis Persistence Models RDB (Snapshotting) Point-in-time snapshots Timeline SET A INCR B SET C Snapshot fork() Parent Child dump.rdb Potential data loss window Pro: Fast, compact for backups Con: Risk of data loss since last save AOF (Journaling) Append-only log of operations appendonly.aof SET A 1 *3\r\n$3\r\nSET... INCR B *2\r\n$4\r\nINCR... SET C 3 *3\r\n$3\r\nSET... fsync policy (e.g., `everysec`) Pro: High durability (max 1s data loss) Con: Larger file, potential write overhead

Core Idea: Eviction Policies

When Redis hits its `maxmemory` limit, an eviction policy is the rule used to delete keys to make room for new data. Common choices like LRU (Least Recently Used) and LFU (Least Frequently Used) help preserve the most relevant data in the cache.

Redis Memory Eviction Policies Flowchart Memory Eviction Decision Flow New Write Command Arrives maxmemory reached? No Yes Write Succeeded Consult `maxmemory-policy` (e.g., allkeys-lru, noeviction) LRU: Least Recently Used Access Order: [K1, K2, K3, K1, K4] [K4, K1, K3, K2] <-- Recency Evict Candidate: K2 (Not accessed for the longest time) LFU: Least Frequently Used Access Counts: K1: 20, K2: 55, K3: 3 Evict Candidate: K3 (Accessed the fewest times) noeviction Return error to client

Core Idea: Cache-Aside Strategy

In this common pattern, your application code takes responsibility for the cache logic. It first requests data from Redis. If it's a "miss," the application queries the primary database, then populates the cache for future requests.

Cache-Aside (Lazy Loading) Flowchart Cache-Aside Read Flow App needs user data 1. Query Redis Cache 2. Data Found? YES (Hit) 3. Return Data to App END NO (Miss) 3. Query Database 4. Store in Redis (with TTL) 5. Return Data to App

Check Your Understanding

1. True or False: Redis is multi-threaded, so adding more CPU cores always improves command execution speed. False. The core command execution is single-threaded. More cores help with background I/O, not the speed of a single command.

2. True or False: The `noeviction` policy is the best choice for a high-traffic web session cache. False. `noeviction` would cause errors when the cache is full. `allkeys-lru` or `allkeys-lfu` are much better choices.

3. True or False: In the Cache-Aside pattern, Redis automatically fetches data from the database on a cache miss. False. The application is responsible for fetching from the database and populating the cache.

Common Misconceptions

  • Mistake: Exposing Redis to the internet, thinking the default `protected-mode` is enough security.
    Correction: Always `bind` to a private IP/localhost and set a strong password with `requirepass`.
  • Mistake: Forgetting to set `maxmemory`, allowing Redis to consume all system RAM and get terminated by the OS.
    Correction: Always define a `maxmemory` limit and a sensible `maxmemory-policy` like `allkeys-lru`.
  • Mistake: Using default persistence settings (RDB snapshots) for a purely volatile cache.
    Correction: Disable persistence (`save ""` and `appendonly no`) to eliminate disk I/O and maximize performance.

Summary & Key Takeaways

  • Hardware is Foundation: Redis performance depends on RAM size, single-core CPU speed, and low network latency.
  • Configure Deliberately: The `redis.conf` file is your control panel. Prioritize security (`bind`, `requirepass`) and memory management (`maxmemory`).
  • Choose Persistence Wisely: Disable persistence for volatile caches. Use AOF for durability. RDB is best for backups.
  • Implement Smart Caching: Use TTLs to expire stale data automatically and implement the Cache-Aside pattern in your application for robust logic.

Exit Ticket

Describe the three most important `redis.conf` directives you would set for a new production Redis instance used for session caching, and justify each choice.

(You can discuss with a partner or write down your answer.)

Questions?

Thank You!